CVE-2026-15076
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIn versions up to and including 4.5.29 (4.x branch) and 5.1.4 (5.x branch), the WebClientSession component of Eclipse Vert.x Web Client does not validate that the Domain attribute of a Set-Cookie response header matches the originating server's domain, in violation of RFC 6265 section 5.3. An attacker who controls any server that the victim application contacts can inject a cookie scoped to an arbitrary third-party domain; because the session store performs no cross-domain ownership check, it stores and later transmits that cookie to the targeted domain. When the victim application subsequently sends a request to the targeted domain using the same WebClientSession, it presents the attacker-injected cookie, causing the receiving service to process the request under the attacker's account. Sensitive data included in the victim application's requests, such as payment amounts, card details, or other API payloads, may then be accessible to the attacker through their own account on that service.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceThe Eclipse Vert.x Web Client's WebClientSession component fails to validate the Domain attribute of Set-Cookie headers against the originating server's domain, per RFC 6265 section 5.3. This allows malicious servers to inject cookies scoped to arbitrary third-party domains, which the session store then stores and subsequently transmits to targeted domains, enabling account takeover.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data>= 4.0.0, <= 4.5.29>= 5.0.0, <= 5.1.4CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- None
- Availability
- None
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify Vert.x version in useInspect your project's dependency manifest (pom.xml, build.gradle, package.json, or equivalent) for the Eclipse Vert.x Web Client dependency and note the version numberAffected if The reported version falls within 4.0.0 to 4.5.29 or 5.0.0 to 5.1.4
-
Locate WebClientSession usageSearch your codebase for imports or references to io.vertx.ext.web.client.WebClientSession or equivalent WebClientSession class usageAffected if WebClientSession is imported and used in your application code
-
Identify cookie storage mechanismSearch for session store implementations, CookieHandler configurations, or custom cookie handling logic that processes Set-Cookie headers from HTTP responsesAffected if Your code stores or processes cookies received from remote servers via WebClientSession
-
Verify cookie domain validationReview your cookie handling code for domain validation logic that checks the Domain attribute of Set-Cookie headers against the request URL's hostname per RFC 6265 section 5.3Affected if No domain validation exists, or the Domain attribute is being accepted without verification against the originating server's domain
-
Check for third-party cookie injectionInspect stored cookies or session data to see if cookies with Domain attributes pointing to domains different from your request hostname are being persistedAffected if Cookies with arbitrary third-party Domain attributes are being stored and could be replayed to targeted domains
You are affected if you use Vert.x WebClientSession within the vulnerable version range and your application stores cookies from server responses without validating that the Domain attribute matches the originating server's hostname.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedUpgrade Eclipse Vert.x Web Client to a version beyond 4.5.29 (4.x branch) or 5.1.4 (5.x branch) that includes domain validation for Set-Cookie headers. If no patched version is available, implement application-layer validation of cookie domain attributes before storing them in the session.
Vert.x 4.5.30+ (4.x branch) or Vert.x 5.1.5+ (5.x branch)
- 1. Identify all applications using Eclipse Vert.x Web Client (WebClientSession) versions 4.0.0 through 4.5.29 or 5.0.0 through 5.1.4
- 2. Upgrade Vert.x dependency to version 4.5.30 or later for 4.x applications, or version 5.1.5 or later for 5.x applications
- 3. Rebuild and redeploy the application with the updated Vert.x dependency
- 4. Verify the fix by testing that Set-Cookie headers with mismatched Domain attributes are rejected or domain-scrubbed
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation4.0 h
- Implementation2.0 h
- Testing8.0 h
- Review / QA3.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,640.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-15076 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-15076 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data