Security fix · GHSA-6365-7ppr-5r92
Connection created for the wrong upstream for forward_auth + reverse_proxy
Published Jul 10, 2026 · catalog updated Jul 10, 2026 · Connection created for the
Last checked Nov 1, 2026. A connected source was read within the last 7 days.
Open the advisory
Exploitation likelihood is not on this record for GHSA-6365-7ppr-5r92. A missing EPSS score is not a low risk. Compare Connection created for the with the linked advisory before you change production.
Gaps on this record
- The stored product name is a package slug. The name on this page is taken from the title (Connection created for the).
- No vendor fix or required action is stored. Compare the linked advisory before you change production.
- EPSS is missing. A missing score is not a low risk.
- Severity
- Medium—
- Known exploitation
- Not in CISA/VulnCheck KEV
- EPSS
- Awaiting synchronization with FIRST
- Remediation
- Version ranges on file
- Affected products
- go github.com/caddyserver/caddy
### Summary We have found an issue where Caddy is using the wrong connection when a handler has both and . Occasionally users were mentioning requests returning with 404 for not apparent reason. Unfortunately enabling detailed Caddy logs did not help as these were not correct, insisting their upstreams were returning 404 for endpoints which are known to exist. Only showed the real issue; the request meant for the endpoint was being sent on the wrong connection which did not have the expected endpoints and thus replied with 404. For our setup we have downgraded to 2.10.2 which is not affected. ### Details Commit 8aca108d2c9d9e9ff3a39ff00684ea58df1338f6 seems to be the cause as the parent 156ce99d3a46be8cefe8502b2c30b757e4deb79f does not exhibit this behavior. ### PoC The issue only happened sporadically and seemingly also fixed itself sometimes when connections were likely closed. To reproduce reliably we need to make the race condition window larger by adding a sleep. We can apply it to both commits to confirm it is not the source of any issue: For 8aca108d2c9d9e9ff3a39ff00684ea58df1338f6 (to make the race more likely): For 156ce99d3a46be8cefe8502b2c30b757e4deb79f (where it will *NOT* cause issues): Now, to reproduce we use this Caddyfile: And then we have a program which causes it to happen: - Listens on the expected endpoint - Listens on the expected endpoint, counting if it receives a (which it definitely should not) - Requests from Caddy which we expect to hit the with a and then the with a ### Impact This seems pretty severe, it randomly breaks the behavior depending on timing. You could pass a check unexpectedly if the raced connection happens to have the same endpoints and replies with 200 OK. It also breaks functionality by causing unexpected 404 responses making the handler unreliable. ### AI Usage I didn't seen this as part of the template but I can see it in your regular issues, so I added something here. I can say that we used AI to help us find the exac
Are you affected?
Enter the version you run. The result uses only the ranges stored on this record.
The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.
- go github.com/caddyserver/caddy< v2.11.5
How to fix GHSA-6365-7ppr-5r92
Upgrade
GHSA-6365-7ppr-5r92 lists a fix boundary at v2.11.5. Compare the installed build with that boundary before you change production.
Version check
Seen in < v2.11.5
Advisory
Open the inventory_github record and follow its fix.
Official advisories
What to do
Three questions, each answered from this record only. Confirm the vendor advisory before you patch.
Should you patch?
Exploitation likelihood is not on this record for GHSA-6365-7ppr-5r92. A missing EPSS score is not a low risk. Compare Connection created for the with the linked advisory before you change production.
Which versions are affected?
Compare what you have installed with < v2.11.5. Compare the installed version with the linked vendor advisory before you change production.
What should an analyst verify?
No weakness class is stored. EPSS is not on this record yet. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.
Technology hubs
Code
The project this record applies to. Exploit listings stay in References.
Timeline
Detection, updates, and resolution for this record.
Jul 10, 2026 · Maintainer security tabs
Detected
### Summary We have found an issue where Caddy is using the wrong connection when a handler has both and . Occasionally users were mentioning requests returning with 404 for not apparent reason. Unfortunately enabling detailed Caddy logs did not help as these were not correct, insisting their upstreams were returning 404 for endpoints which are known to exist. Only showed the real issue; the reque
Jul 10, 2026 · Maintainer security tabs
Updated
### Summary We have found an issue where Caddy is using the wrong connection when a handler has both and . Occasionally users were mentioning requests returning with 404 for not apparent reason. Unfortunately enabling detailed Caddy logs did not help as these were not correct, insisting their upstreams were returning 404 for endpoints which are known to exist. Only showed the real issue; the reque
Sources
- Maintainer security tabsVendor advisoryGHSA-6365-7ppr-5r92
### Summary We have found an issue where Caddy is using the wrong connection when a handler has both and . Occasionally users were mentioning requests returning with 404 for not apparent reason. Unfortunately enabling detailed Caddy logs did not help as these were not correct, insisting their upstreams were returning 404 for endpoints which are known to exist. Only showed the real issue; the reque
github.com
Freshness
Last verified in this catalog Jul 10, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.
- Maintainer security tabsNov 1, 2026