CVE-2026-22874: Gitea webhook and migration allow-list filtering permits SSRF

Published Jul 3, 2026
·
Updated

Summary

Gitea's default SSRF allow-list (MatchBuiltinExternal, used by both webhook delivery and repository migrations) relies on Go's standard library net.IP.IsPrivate(), which only covers RFC 1918 and RFC 4193. As a result, several IP ranges commonly used for cloud metadata services, internal networks, and IPv6 transition mechanisms are not blocked, allowing authenticated users to send HTTP requests to those destinations and read the responses via the webhook history UI.

Details

The vulnerability lives in HostMatchList.checkIP, specifically line 103:

go case MatchBuiltinExternal: if ip.IsGlobalUnicast() && !ip.IsPrivate() { return true }

net.IP.IsPrivate() recognises only: - 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (RFC 1918) - fc00::/7 (RFC 4193 IPv6 ULA)

It does not recognise:

| Range | Description | |---|---| | 100.64.0.0/10 | RFC 6598 Carrier-Grade NAT | | 168.63.129.16/32 | Azure WireServer metadata endpoint | | 172.32.0.0/11 | Non-RFC1918 portion of 172.0.0.0/8 (real-world internal use) | | 64:ff9b::/96 | RFC 6052 IPv6 NAT64 (can embed 169.254.169.254) | | 2001::/32 | RFC 4380 Teredo tunneling | | 2002::/16 | RFC 3056 6to4 | | 2001:db8::/32 | RFC 3849 documentation |

The default is reached by webhook delivery at services/webhook/deliver.go#L312-L316 and by repository migrations at services/migrations/migrate.go#L522.

The SSRF is not blind. Webhook delivery captures the response status, headers, and up to 1 MiB of body (services/webhook/deliver.go#L259-L270) and renders them in the webhook history UI (templates/repo/settings/webhook/history.tmpl#L75-L85), so attackers can read everything the targeted internal service returns.

Impact

An authenticated user who can create or modify a webhook can:

- Reach cloud metadata endpoints (AWS IMDS via NAT64 64:ff9b::a9fe:a9fe, Azure WireServer 168.63.129.16) - Probe and exfiltrate from internal services on CGNAT (100.64.0.0/10) or non-RFC1918 172.x ranges - Read full HTTP response bodies through the webhook history UI

The same default is applied to repository migrations, broadening the attack surface to users who can trigger a migration.

Proof of Concept

The attached patch (giteassrftest.patch) adds TestSSRFBypassRanges to the existing test file. It uses Go subtests so each vulnerable range is its own named failing test case.

Run with: go test -v ./modules/hostmatcher -run TestSSRFBypassRanges

Expected result on 4c37f4dacbac022f7beca75272439331f0368830: - 8 PASS — RFC 1918, IPv6 private ranges, and legitimate public IPs (control cases) - 10 FAIL — Each failing subtest is a documented SSRF bypass

Sample failure output: --- FAIL: TestSSRFBypassRanges/CGNAT100.64.0.0/10(RFC6598) Error: Not equal: expected: false, actual: true Messages: ip=100.64.0.1 --- FAIL: TestSSRFBypassRanges/AzureWireServer168.63.129.16 Error: Not equal: expected: false, actual: true Messages: ip=168.63.129.16 --- FAIL: TestSSRFBypassRanges/IPv6NAT64embeddedAWSIMDS169.254.169.254 Error: Not equal: expected: false, actual: true Messages: ip=64:ff9b::a9fe:a9fe

Suggested Remediation

I'd suggest treating the design of MatchBuiltinExternal as the bug — IsPrivate() is too narrow a definition of "internal." A comprehensive deny-list approach is what's needed here. For reference, CC-Tweaked's AddressPredicate.PrivatePattern is a good reference list, blocking each of the ranges named in the table above plus a few others (multicast, broadcast, TEST-NET, etc.).

The exact remediation is at your discretion.

References

- Vulnerable function: modules/hostmatcher/hostmatcher.go#L96-L114 - Default for webhooks: services/webhook/deliver.go#L312-L316 - Default for migrations: services/migrations/migrate.go#L522 - Response captured: services/webhook/deliver.go#L259-L270 - Response rendered: templates/repo/settings/webhook/history.tmpl#L75-L85 - Go stdlib net.IP.IsPrivate(): <https://pkg.go.dev/net#IP.IsPrivate> - CC-Tweaked reference deny-list: AddressPredicate.java#L116-L169 - Go subtests pattern: <https://go.dev/blog/subtests> - RFC 6598 (CGNAT), RFC 6052 (NAT64), RFC 4380 (Teredo), RFC 3056 (6to4), RFC 3849 (documentation)

---

Patch <a name="patch"></a>

Proposed giteassrftest.patch:

diff diff --git a/modules/hostmatcher/hostmatchertest.go b/modules/hostmatcher/hostmatchertest.go index c781847..0b39e60 100644 --- a/modules/hostmatcher/hostmatchertest.go +++ b/modules/hostmatcher/hostmatchertest.go @@ -159,3 +159,56 @@ func TestHostOrIPMatchesList(t testing.T) { } test(cases) } + +// TestSSRFBypassRanges verifies that the "external" filter (the default used by +// webhook delivery and repository migrations) blocks dangerous IP ranges. +// +// Each subtest's allowed field is the expected return value of MatchHostOrIP: +// - false: the IP should be blocked (rejected by the filter) +// - true: the IP should be allowed (a legitimate public destination) +// +// Subtests that FAIL are documented SSRF bypasses: IP ranges that should be +// blocked but are incorrectly allowed because the underlying check relies on +// net.IP.IsPrivate(), which only covers RFC 1918 and RFC 4193. +func TestSSRFBypassRanges(t testing.T) { + type tc struct { + ip net.IP + allowed bool + } + + hl := ParseHostMatchList("", "external") + + cases := map[string]tc{ + // RFC 1918 / IPv6 private ranges - correctly blocked + "RFC1918 10.0.0.0/8": {net.ParseIP("10.0.0.1"), false}, + "RFC1918 172.16.0.0/12": {net.ParseIP("172.16.0.1"), false}, + "RFC1918 192.168.0.0/16": {net.ParseIP("192.168.1.1"), false}, + "IPv6 loopback ::1": {net.ParseIP("::1"), false}, + "IPv6 link-local fe80::/10": {net.ParseIP("fe80::1"), false}, + "IPv6 ULA fd00::/8": {net.ParseIP("fd00::1"), false}, + + // Legitimate public IPs - correctly allowed + "Public IPv4 (Google DNS)": {net.ParseIP("8.8.8.8"), true}, + "Public IPv6 (Google DNS)": {net.ParseIP("2001:4860:4860::8888"), true}, + + // SSRF bypasses - the assertions below intentionally describe the + // expected secure behavior (allowed=false). Each failing subtest is + // a documented bypass. + "CGNAT 100.64.0.0/10 (RFC 6598)": {net.ParseIP("100.64.0.1"), false}, + "CGNAT 100.127.255.254 (RFC 6598)": {net.ParseIP("100.127.255.254"), false}, + "Azure WireServer 168.63.129.16": {net.ParseIP("168.63.129.16"), false}, + "Non-RFC1918 172.32.0.0/11": {net.ParseIP("172.32.0.1"), false}, + "Non-RFC1918 172.45.0.0/16": {net.ParseIP("172.45.0.1"), false}, + "IPv6 NAT64 64:ff9b::/96 (RFC 6052)": {net.ParseIP("64:ff9b::1"), false}, + "IPv6 NAT64 embedded AWS IMDS 169.254.169.254": {net.ParseIP("64:ff9b::a9fe:a9fe"), false}, + "IPv6 Teredo 2001::/32 (RFC 4380)": {net.ParseIP("2001::1"), false}, + "IPv6 6to4 2002::/16 (RFC 3056)": {net.ParseIP("2002::1"), false}, + "IPv6 documentation 2001:db8::/32 (RFC 3849)": {net.ParseIP("2001:db8::1"), false}, + } + + for name, c := range cases { + t.Run(name, func(t testing.T) { + assert.Equalf(t, c.allowed, hl.MatchHostOrIP("", c.ip), "ip=%v", c.ip) + }) + } +}

Credit

This vulnerability was uncovered by @JLLeitschuh of the @braze-inc security team.

Other sources

Gitea versions up to and including 1.26.2 have incomplete SSRF protection in webhook and migration allow-list filtering.

MITRE

Affected Software

2 affected componentsFixes available
Gitea Gitea<=1.26.2
go/code.gitea.io/gitea<1.26.3
1.26.3

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/code.gitea.io/gitea to a version that resolves this vulnerability.

    Fixed in 1.26.3
  2. Compensating control

    Treat Gitea webhook and repository migration SSRF destination allow-listing as incomplete for ranges such as CGNAT (100.64.0.0/10), Azure WireServer 168.63.129.16, and IPv6 transition/NAT64 mechanisms (e.g., 64:ff9b::/96). Enforce a deny-list or network-level egress restriction for these IP ranges so authenticated users cannot reach cloud metadata/internal services and read responses via the webhook history UI.

Event History

Jul 3, 2026
CVE Published
via MITRE·08:19 PM
Data Sourced
via MITRE·08:19 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·09:16 PM
DescriptionSeverityWeakness
Jul 21, 2026
Advisory Published
via GitHub·08:27 PM
Data Sourced
via GitHub·08:27 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-22874?

The severity of CVE-2026-22874 is critical with a score of 9.6.

2

What vulnerability does CVE-2026-22874 address?

CVE-2026-22874 addresses incomplete SSRF protection in Gitea's webhook and migration allow-list filtering.

3

How do I fix CVE-2026-22874?

To fix CVE-2026-22874, upgrade Gitea to version 1.26.3 or later where the SSRF protection is properly implemented.

4

What versions of Gitea are affected by CVE-2026-22874?

Gitea versions up to and including 1.26.2 are affected by CVE-2026-22874.

5

What impact does CVE-2026-22874 have on Gitea users?

CVE-2026-22874 allows for server-side request forgery (SSRF), potentially exposing sensitive internal services to unauthorized access.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203