CVE-2026-41417
Is CVE-2026-41417 real, exploitable, or a false positive? Here's the community verdict.
Community verdict: No field verdicts yet. Be the first practitioner to weigh in.
signals
public sources
Moderate signals. Triage by your actual exposure and reachability.
cisa ssvc
CISA Vulnrichment · assessed
CISA decision, by how critical the affected system is to you:
- low impact → Track
- medium impact → Track
- high impact → Attend
Track: normal patch cycle · Track*: watch closely · Attend: patch sooner · Act: patch now. About SSVC ↗
affected packages
GHSA-v8h7-rr48-vmmv · GitHub rates it moderate- Mavenio.netty:netty-codec-http
- Vulnerable
- < 4.1.133.Final; ≥ 4.2.0.Alpha1, < 4.2.13.Final
- Fixed in
- 4.1.133.Final, 4.2.13.Final
Source: GitHub Advisory Database (CC-BY 4.0), via OSV.dev. Check your lockfile version against the ranges above.
scanner noise
anonymous, aggregated from real reports · via Denoizr| Scanner | Flagged in | Turned out noise |
|---|---|---|
| Mend | 2 scans | 0% |
How often this CVE was flagged by each scanner and how much turned out to be noise (false positives), aggregated anonymously from de-noised reports. Higher noise means the alert is more often not a real risk — verify your exposure.
baseline read
auto · not a community verdict
Low signal — verdict needed
Few public signals point to active risk. Whether a scanner hit here is a true or false positive depends on your version and config — community verdicts decide.
Based on CVSS · FIRST EPSS
Confirm or dispute →CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Netty allows request-line validation to be bypassed when a `DefaultHttpRequest` or `DefaultFullHttpRequest` is created first and its URI is later changed via `setUri()`. The constructors reject CRLF and whitespace characters that would break the start-line, but `setUri()` does not apply the same validation. `HttpRequestEncoder` and `RtspEncoder` then write the URI into the request line verbatim. If attacker-controlled input reaches `setUri()`, this enables CRLF injection and insertion of additional HTTP or RTSP requests, leading to HTTP request smuggling or desynchronization on the HTTP side and request injection on the RTSP side. This issue is fixed in versions 4.2.13.Final and 4.1.133.Final.
References
Published
Embed this verdict
[](https://www.truepositive.app/cve/CVE-2026-41417)<a href="https://www.truepositive.app/cve/CVE-2026-41417"><img src="https://www.truepositive.app/cve/CVE-2026-41417/badge.svg" alt="TruePositive verdict for CVE-2026-41417"></a>Live badge that updates automatically as the community verdict changes.
timeline
- CISA SSVC assessment · exploitation: poc
- Published by NVD
Score and exploit changes tracked since .
Community ground truth
Be the first practitioner to weigh in
So far this is only TruePositive's editorial baseline from public sources. Add your real-world verdict below — it becomes the signal the next person triaging this relies on.
🥇 The first 50 practitioners to contribute earn a Founding Contributor badge.
In your experience, is this finding real and exploitable?
awaiting field verdictsCurated baseline: A curated baseline from public sources, shown separately from community verdicts.
No account needed. Anonymous verdicts post as an unverified signal. Log in to make yours verified and earn reputation.
Field notes & remediation
Verdicts are the quick signal. Notes are the evidence and fixes behind them.
- 0
No confirmed in-the-wild exploitation or public exploit was found for this yet.
Add a field note or remediationoptional
Related CVEs
Same weakness: CWE-93.