One Header to Rule Them All: Critical Gitea Bug Lets Attackers Walk Right In

It took just 13 days after the advisory went public for attackers to start exploiting a critical vulnerability in Gitea, the popular self-hosted Git service. The bug, tracked as CVE-2026-20896, carries a CVSS score of 9.8. And the attack vector is almost absurdly simple: a single HTTP header containing a valid username.

No password. No token. Just a header. Sysdig’s senior director of threat research, Michael Clark, confirmed that the company’s sensors caught the first in-the-wild hit less than two weeks after the flaw was disclosed. The attempt was linked to what Clark described as a “VPN-exit scanner that grabbed access.”

This isn’t a theoretical risk. It’s happening now.

What Makes CVE-2026-20896 So Dangerous?

The vulnerability lives in Gitea’s reverse-proxy authentication mechanism — specifically in the official Docker images. Security researcher Ali Mustafa, who discovered the bug, explains that in Gitea Docker images before version 1.26.3, the default configuration allows connections from any source IP address. It doesn’t enforce an allowlist.

Here’s the problem: when reverse-proxy authentication is enabled, Gitea should only trust a header that was set by the proxy itself. But because of this flaw, anyone who can reach the Gitea container’s HTTP port directly — sidestepping the authenticating proxy — can impersonate any user whose login name they know or can guess.

And guess what? Admin accounts are the obvious target. “Any process that can reach the Gitea container’s HTTP port directly — not through the intended authenticating proxy — can impersonate any user whose login name is known or guessable. Admin accounts are the obvious targets,” Mustafa noted.

The fix, rolled out in Gitea versions 1.26.3 and 1.26.4, makes reverse-proxy authentication an opt-in feature. That’s a smart move — it means the dangerous default is no longer the default.

What Attackers Can Do Once They’re In

The consequences of a successful exploit are severe. Clark laid it out bluntly: a Gitea user can read and write their own repositories, including private ones. That means attackers can access:

• The code your organization ships to production
• Secrets developers accidentally committed — API keys, database credentials, deploy tokens
• CI/CD configuration files
• Deploy keys that can unlock other systems

In other words, a single header can lead to the complete compromise of everything Gitea holds. Code, secrets, infrastructure access — all up for grabs.

How Many Instances Are Exposed?

Sysdig’s research found roughly 6,200 Gitea instances accessible from the internet. How many of those are running vulnerable versions is unclear. But given that the flaw was only recently patched, and that many organizations are slow to update, the number could be significant.

If you’re running Gitea in a Docker container, now is the time to check your version. The attack surface is real, and the window for patching is closing fast.

What You Should Do Right Now

The advice from researchers is straightforward: update your Gitea deployments immediately. If you’re on a version before 1.26.3, you’re exposed. The patch changes the default behavior so that reverse-proxy authentication must be explicitly enabled, rather than being on by default.

Beyond updating, consider whether you even need reverse-proxy authentication. If you do, make sure your proxy is properly configured to set the trusted header, and that no other process can reach the Gitea container’s HTTP port directly. Network segmentation is your friend here.

This isn’t the first time Gitea has been in the spotlight for security issues. A previous vulnerability exposed roughly 30,000 deployments to attacks. And with critical Adobe ColdFusion vulnerabilities and actively exploited Microsoft SharePoint flaws also making headlines, it’s clear that the threat landscape is crowded. Don’t let your Gitea instance become the weak link.

Patch now. Because one header is all it takes.

A public issue, a private leak — no credentials required

Security researchers at Noma Security have demonstrated a troubling attack vector targeting GitHub Agentic Workflows. The premise is deceptively simple: an attacker opens a normal-looking issue on a public repository. That’s it. No stolen credentials. No direct access to the organization’s internal systems.

If the targeted organization has granted the agent read access across its repositories — including private ones — the contents of those private repos can be exfiltrated. The attack works because the agent, designed to automate responses and actions, can be tricked into following instructions embedded in the issue itself.

The finding raises serious questions about how much trust organizations are placing in automated workflows that interact with untrusted input.

How the attack works: poisoning the prompt

GitHub Agentic Workflows are a relatively new feature that allows AI-driven agents to respond to events like issue creation, pull requests, or comments. They can be configured with broad permissions — including read access to private repositories — to perform tasks like triaging bugs, summarizing code changes, or generating patches.

Noma’s research shows that an attacker can craft a public issue containing what amounts to a prompt injection. The agent, upon processing the issue, interprets the injected instructions as legitimate commands. In the proof of concept, the attacker instructed the agent to read files from a private repository and then send those files to an external server controlled by the attacker.

“The agent doesn’t know the difference between a legitimate task and a malicious one,” said a Noma researcher. “It just follows the instructions it’s given, based on the context it has access to.”

The entire chain requires no exploitation of GitHub’s infrastructure — just a public issue and an agent with overly broad permissions.

Why this is different from a typical supply chain attack

Most supply chain attacks on GitHub involve compromised credentials, malicious dependencies, or vulnerabilities in Actions runners. This attack is different. It exploits the trust model of the agent itself.

The agent is given a high-privilege token or access scope — often for convenience — and then exposed to user-generated content that can manipulate its behavior. It’s a classic prompt injection vulnerability, but applied to an infrastructure automation context rather than a chatbot.

“The real issue is the gap between the permissions an agent needs to do its job and the permissions it actually gets,” the researcher added. “Teams often err on the side of giving too much access because it’s easier than fine-tuning.”

Who is most at risk

Any organization using GitHub Agentic Workflows with read access to private repositories is potentially vulnerable. That includes:

• Companies using agents for automated code review or issue triage across both public and private repos
• Open-source projects where maintainers have connected agents to internal repositories for dependency management or security scanning
• Teams that have not restricted the agent’s scope to specific repositories or actions

The attack surface is particularly wide for organizations that run public repositories alongside private ones under the same GitHub organization. A single public issue on any public repo in that organization can trigger the agent — if the agent is configured to listen to all issues.

Mitigation: least privilege and input sanitization

Noma Security recommends several practical steps to reduce the risk:

• Restrict agent permissions. Give the agent only the minimum access it needs — ideally scoped to specific repositories and specific actions. Avoid granting blanket read access across all repos.
• Use a separate agent for public vs. private repos. If an agent must interact with public issues, keep it isolated from private data. Use a different agent or a different token for internal workflows.
• Sanitize and validate inputs. Treat any content from public issues, comments, or pull requests as untrusted. Implement checks that strip or escape potentially malicious instructions before they reach the agent.
• Audit agent behavior. Log all actions taken by the agent and review them for anomalies. Set up alerts for unexpected file reads or data exfiltration patterns.

GitHub has been notified of the finding. The company has not yet issued a public statement or patch, but the vulnerability is inherent to how agents interpret natural language instructions — not a bug in GitHub’s code per se.

The bigger picture: agent security is still immature

This research is a reminder that AI agent security is still in its early days. As more platforms integrate autonomous agents that can read, write, and act on data, the attack surface expands dramatically. The same qualities that make agents powerful — their ability to interpret context and take independent action — also make them vulnerable to manipulation.

“We’re seeing the same pattern we saw with early web applications,” said a security analyst not involved in the research. “Developers are excited about what agents can do, and security is an afterthought. That’s how breaches happen.”

For now, the safest approach is to assume that any public-facing input can be weaponized. Until agent platforms build robust guardrails — like mandatory input validation, permission boundaries that cannot be overridden by instructions, and human-in-the-loop approval for sensitive actions — organizations should treat agentic workflows with the same caution they’d give any internet-facing service.

The Noma team plans to release a full technical write-up and a proof-of-concept video in the coming weeks. For organizations already using GitHub Agentic Workflows, the time to audit permissions is now — before an attacker opens that first issue.

Injective Labs GitHub Hack: What Happened

Attackers breached the Injective Labs SDK project’s GitHub repository and used it to push a malicious package to the npm registry. The package, @injectivelabs/sdk-ts@1.20.21, was designed to steal cryptocurrency wallet private keys and mnemonic seed phrases.

The compromised version contained fake telemetry functionality. Instead of collecting legitimate usage data, it exfiltrated sensitive wallet information. Anyone who installed this package risked losing access to their crypto funds.

This is a classic supply chain attack. The attackers didn’t break into individual developer machines — they targeted the source code repository itself, injecting malicious code that downstream users would trust and install.

How the Malicious Package Stole Wallet Keys

The fake telemetry in @injectivelabs/sdk-ts@1.20.21 didn’t just phone home with harmless metrics. It specifically targeted cryptocurrency wallet private keys and mnemonic seed phrases — the two pieces of data that give full control over a blockchain wallet.

Once a developer or project integrated this compromised package, the malicious code would activate during runtime. It collected wallet credentials and sent them to servers controlled by the attackers. The code was disguised as routine telemetry, making it harder to spot during code reviews.

Private keys are the ultimate prize in crypto theft. With a private key, an attacker can sign transactions and move funds without any additional authentication. Seed phrases (also called recovery phrases) are equally dangerous — they can regenerate an entire wallet on any device.

Timeline and Response

Security researchers identified the malicious package shortly after it appeared on npm. The compromised version was published on an unknown date, but the Injective Labs team moved quickly once alerted.

The malicious version has been removed from the npm registry. Injective Labs also published a security advisory warning users not to use @injectivelabs/sdk-ts@1.20.21 and to immediately rotate any wallet keys that may have been exposed.

If you or your project used this specific version, the safest course is to:

• Check your package-lock.json or yarn.lock for @injectivelabs/sdk-ts@1.20.21
• Treat any wallet that was active on a machine with this package as compromised
• Generate new wallet addresses and transfer funds immediately
• Run a full security audit of your development environment

Lessons for the Crypto Development Community

This incident is a stark reminder that trust in open-source packages has limits. The npm ecosystem, like PyPI and RubyGems, has seen repeated supply chain attacks. Crypto projects are especially attractive targets because a successful breach yields direct financial gain.

What makes this attack particularly insidious is that it targeted the crypto wallet key theft vector through a trusted SDK. Developers using Injective Labs’ tools likely had no reason to suspect the package was compromised. The attackers exploited that trust.

For teams building on blockchain infrastructure, several practices can reduce risk:

Verify Package Integrity

Always check package hashes against official sources. npm supports integrity checking via package-lock.json. If a package’s hash changes unexpectedly, that’s a red flag.

Pin Dependencies

Don’t use loose version ranges like ^1.20.0. Pin to exact versions and review updates manually. This won’t prevent all attacks, but it buys time to vet new releases.

Monitor for Anomalies

Sudden changes in package behavior — like new network requests or unexpected file system access — should trigger immediate investigation. Tools like Socket can automate this monitoring.

What Injective Labs Users Should Do Now

If you’re an Injective Labs SDK user, the immediate priority is determining whether you ever installed version 1.20.21. Even if you’ve since updated, the damage may already be done.

Check your npm audit logs and CI/CD pipeline history. If the malicious package ran in any environment that had access to wallet keys, those keys are compromised. The attackers may have already copied them.

For developers who suspect exposure, the safest move is to treat all wallets used in that environment as burned. Generate fresh wallets and transfer funds. This is inconvenient, but it’s far cheaper than losing everything to a delayed attack.

The Injective Labs team has been transparent about the breach, which is commendable. But the incident underscores a broader truth: in crypto, a single compromised dependency can empty your wallet in seconds. Vigilance isn’t optional — it’s the price of participation.