Does Gitingest symlink flaw expose server files to unauthenticated access?

The short version

• Gitingest versions up to 0.3.1 contain a symlink following vulnerability.
• Unauthenticated attackers can read server files via the ingest_query function.
• The flaw allows retrieval of files the service user can access.

The details

Gitingest, a tool developed by coderamp-labs, contains a security flaw in versions up to 0.3.1. The issue, tracked as CVE-2026-110767, involves improper handling of symbolic links during single-file blob ingestion. According to the National Vulnerability Database, the flaw allows unauthenticated attackers to read files on the server. The vulnerability arises when the application processes blob URLs submitted by users without adequately verifying the target path.

An attacker can exploit this by committing a symbolic link to a public repository. By submitting the blob URL of that symlink to the Gitingest service, the server follows the link and returns the contents of the pointed-to file. This mechanism bypasses standard access controls for the ingestion process. The service user’s permissions determine which files are accessible. Any file readable by the service account can be exfiltrated through this method.

The maximum size of a file that can be retrieved is 10 MB. This limit restricts the volume of data per request but does not prevent access to sensitive configuration files or credentials. The flaw is rated high severity with a CVSS score of 8.7. The weakness is categorised under CWE-59, which relates to improper link resolution before file access.

The context

This vulnerability highlights risks in tools that process user-supplied file references. When applications follow symbolic links without strict validation, they can expose unintended parts of the filesystem. The National Vulnerability Database records this issue as affecting the ingest_query component specifically. The flaw demonstrates how a seemingly minor parsing oversight can lead to significant information disclosure.

Next steps

Organisations using Gitingest should verify their current version immediately. If running version 0.3.1 or earlier, assess the exposure of the service to unauthenticated users. Review the permissions of the service account running the application to limit potential damage. Monitor for any vendor announcements regarding patches or workarounds.

What defenders should look for

Teams usually monitor web server logs for unusual request patterns involving blob URLs. Look for requests that result in large response sizes or access to non-standard file types. Check whether the application is receiving inputs from unauthenticated sources that trigger file read operations. Inspect access logs for repeated attempts to access specific paths or symbolic links. Verify that the service account has minimal file system permissions. Ensure that logging captures the full request URI and any associated metadata. Review alerts for potential data exfiltration indicators.

What to do and how to stay safe: Gitingest

• Audit all instances of Gitingest to confirm they are not running vulnerable versions.
• Restrict network access to the Gitingest service to prevent unauthenticated exploitation.
• Limit the file system permissions of the service account to reduce impact.
• Monitor logs for suspicious blob URL submissions and large file responses.

Step-by-step guide: How Virtual Patching Works: The Mechanics Behind Inline Protection

General security guidance from the Honeypot Daily newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of Gitingest are affected by CVE-2026-110767?

Versions up to and including 0.3.1 are affected by this vulnerability.

What is the maximum file size an attacker can read?

An attacker can read files up to 10 MB in size.

Is authentication required to exploit this flaw?

No, the vulnerability allows unauthenticated attackers to read server files.