{ "schema": 1, "generated_at": "2026-11-06", "note": "Generated from data/assessments/ of vaadin/cve-status. The purl carries no version: applicability is the affects range, which is a platform version range. Purls are canonical and percent decoded, so `pkg:npm/@scope/name` here is `pkg:npm/%40scope/name` in a scanner report, and a consumer has to decode before comparing. An entry whose match is `prefix` ends in `*` and covers every purl under it. Editing this file has no effect, change the verdict in cve-status instead.", "entries": [ { "purl": "pkg:javascript/DOMPurify", "cves": [ "CVE-2026-116802", "CVE-2026-116803", "CVE-2026-116804", "GHSA-c6gr-qvv4-5v3f", "GHSA-cg2g-xh64-v4q7", "GHSA-mrv2-3pqr-j5jr" ], "aliases": [], "description": "The DOMPurify your scanner found is inside the JavaScript file that the Vaadin 24.9 and 24.10 build produces, not in node_modules. In that file the only code that calls DOMPurify is the Markdown component, which passes one option, CUSTOM_ELEMENT_HANDLING, and registers no hook. These three advisories need options Vaadin never sets: SAFE_FOR_TEMPLATES with a mode that returns DOM, IN_PLACE with a hook of your own that removes nodes, or PARSER_MEDIA_TYPE set to application/xhtml+xml. Only code of your own can create those conditions. The same library also reaches your build through node_modules, and that copy is answered by npm-dompurify-markdown-24-9-2026-10-23.", "affects": ">=24.9,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:javascript/DOMPurify", "cves": [ "CVE-2021-3163" ], "aliases": [], "description": "CVE-2021-3163 is a Quill advisory, and DOMPurify is not Quill. The production build of Vaadin 24.9 and 24.10 puts DOMPurify, which Markdown uses, and Quill, which Rich Text Editor bundles, into the same generated JavaScript file. Your scanner names that file DOMPurify from its licence header and then matches the Quill CPE against it. The Quill in that file is a separate finding with its own verdict, npm-quill-2021-3163.", "affects": ">=24.9,<25", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:javascript/quill", "cves": [ "CVE-2026-116802", "CVE-2026-116803", "CVE-2026-116804", "GHSA-c6gr-qvv4-5v3f", "GHSA-cg2g-xh64-v4q7", "GHSA-mrv2-3pqr-j5jr" ], "aliases": [], "description": "These three are DOMPurify advisories, and Quill is not DOMPurify. The production build of Vaadin 24.9 and 24.10 puts Quill, which Rich Text Editor bundles, and DOMPurify, which Markdown uses, into the same generated JavaScript file. Your scanner names that file Quill and gives it the DOMPurify advisories that belong to the other library in it. The DOMPurify in that file has its own verdict, javascript-dompurify-markdown-24-9.", "affects": ">=24.9,<25", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:javascript/quill", "cves": [ "GHSA-588m-9qg5-35pq" ], "aliases": [], "description": "The version string matches the advisory and the code does not. Quill before 1.3.7 created editor links with target=\"_blank\" and no rel attribute, so the page you opened could rewrite the address of the page you came from. The copy Vaadin ships is built from 1.3.6 and says so in its header, which is what your scanner read, but the link handler in it already sets rel=\"noopener noreferrer\" before it sets the target. Nothing to upgrade.", "affects": ">=24.4,<24.7", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:javascript/quill", "cves": [ "CVE-2021-3163" ], "aliases": [], "description": "The flaw is real in the Quill that Rich Text Editor bundles, and Vaadin keeps the payload away from it. Every 24 release carries Quill 1.3.6, inside the advisory, and that Quill runs an IMG event handler when it is handed raw HTML. RichTextEditor cleans every value with jsoup in both directions, on what a browser sends and on what setValue shows, and no on* attribute survives. You are exposed only if your code puts HTML into the editor another way: callJsFunction or executeJs with dangerouslySetHtmlValue, or the vaadin-rich-text-editor element used from client code with HTML someone else wrote.", "affects": ">=24.4,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:javascript/quill", "cves": [ "CVE-2025-15056" ], "aliases": [], "description": "Fixed on this line. Platform 25.2.13 pins @vaadin/rich-text-editor 25.2.17, whose vendored Quill escapes the video and formula values before building the semantic HTML, and the reproduction that fires on 25.2.12 does not fire here. The patched copy keeps Quill's own version string 2.0.3, because the fix is ours and there is no Quill release to move to, so a scanner reading the bundled file reports the advisory on this version anyway. That report is stale, not a second finding.", "affects": ">=25.2.13,<25.3", "match": "exact", "applicability": "fixed" }, { "purl": "pkg:javascript/quill", "cves": [ "CVE-2025-15056" ], "aliases": [], "description": "Fixed on this line. Platform 25.3.5 pins @vaadin/rich-text-editor 25.3.5, whose vendored Quill escapes the video and formula values before building the semantic HTML, and the reproduction that fires on 25.3.4 does not fire here. The patched copy keeps Quill's own version string 2.0.3, because the fix is ours and there is no Quill release to move to, so a scanner reading the bundled file reports the advisory on this version anyway. That report is stale, not a second finding.", "affects": ">=25.3.5,<25.4", "match": "exact", "applicability": "fixed" }, { "purl": "pkg:maven/ch.qos.logback/logback-classic", "cves": [ "CVE-2023-6378" ], "aliases": [ "GHSA-vmq6-5m68-f53m" ], "description": "This needs a logback component nobody turns on. The receiver listens on a socket for log events sent by another process and deserialises them, and a crafted stream makes it allocate without bound. It exists only if your logback configuration declares a SocketReceiver or a ServerSocketReceiver, which a Vaadin application does not, and which the Spring Boot default configuration does not either. Look in your logback.xml: if there is no receiver element, nothing is listening.", "affects": "<24", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-core", "cves": [ "CVE-2026-89425" ], "aliases": [ "GHSA-7hhh-6rmp-j9qf" ], "description": "The jar is in your application and the flawed code in it is not reached. CVE-2026-89425 is in UTF8DataInputJsonParser, which Jackson builds only for a java.io.DataInput source, and only bites while reporting an invalid token. On 24.9 and 24.10 Vaadin does give browser data to Jackson, for example the history state of every navigation, but as a String that elemental.json has already parsed and written back, so it is valid JSON and goes to a different parser. Nothing on the 24 series classpaths outside Jackson hands it a DataInput. Code of your own that calls createParser(DataInput) is outside this answer.", "affects": ">=24,<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-databind", "cves": [ "CVE-2026-59889" ], "aliases": [ "GHSA-5gvw-p9qm-jgwh" ], "description": "This one needs two annotations on the same property and a Vaadin application has neither together. When a property carries both @JsonView and @JsonUnwrapped, Jackson replays the buffered JSON for the unwrapped part without checking the active view, so a field meant to be invisible under that view can be written from the incoming document. It needs your own code to deserialise such a type from input somebody else controls. Vaadin does not: it parses requests with elemental.json, its own library, and the only Vaadin classes that use @JsonUnwrapped at all are two in Charts, which are written out to the browser rather than read from it, and no Vaadin class uses @JsonView.", "affects": "<24", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-databind", "cves": [ "CVE-2026-19032", "CVE-2026-54515", "CVE-2026-59889", "CVE-2026-68497", "CVE-2026-77310", "CVE-2026-83557", "CVE-2026-91776", "CVE-2026-91777", "GHSA-mhm7-754m-9p8w" ], "aliases": [ "GHSA-5gvw-p9qm-jgwh", "GHSA-5jmj-h7xm-6q6v", "GHSA-cxp5-3px4-pw24", "GHSA-gx83-3vf8-gh7j", "GHSA-q4xh-88c3-wmh7", "GHSA-vvgp-rfg2-7rr6", "GHSA-wjgm-6hv5-3cvf", "GHSA-wv8q-qhhj-9h54" ], "description": "These need JSON from the browser bound to a Java type that uses a particular Jackson feature. Flow itself only builds trees from browser data: on 24.9 and 24.10, event data, history state and @ClientCallable arguments go through readTree into a JsonNode, which binds nothing. Binding happens into types you write: Hilla endpoint parameters, ReactAdapterComponent state, signal values, Spring controllers. Check those types for a Path, InetAddress, Duration or XMLGregorianCalendar property, @JsonView, @JsonUnwrapped, @JsonIdentityInfo, @JsonTypeInfo or default typing, or ACCEPT_CASE_INSENSITIVE_PROPERTIES. Copilot also binds messages from its browser panel into its own types, some with a Path property: if copilot is on your production classpath, treat this as a risk.", "affects": ">=24,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-databind", "cves": [ "CVE-2023-35116" ], "aliases": [], "description": "The report says Jackson overflows the stack when asked to serialise an object that contains itself, such as a Map that holds a reference to itself. Jackson's maintainers rejected it as a vulnerability and the CVE record carries the disputed tag: an attacker cannot build a cyclic Java object through a request, only your own code can. Scanners flag every jackson-databind before 2.16.0 because that release added a limit on write nesting. Nothing has to be upgraded for it.", "affects": "*", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.google.code.gson/gson", "cves": [ "CVE-2025-53864" ], "aliases": [ "GHSA-xwmg-2g98-w7v9" ], "description": "The advisory is about Nimbus JOSE + JWT, not gson. Its own text says the Nimbus flaw is independent of gson, and GitHub's advisory for it names only com.nimbusds:nimbus-jose-jwt. Some scanners still match gson because the osv.dev copy of the CVE carries a commit range on the gson repository, taken from a gson commit it references, so every gson up to 2.11.0 matches by commit rather than by advisory. Nothing has to be upgraded for it.", "affects": "*", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.google.guava/guava", "cves": [ "CVE-2018-10237", "CVE-2020-8908", "CVE-2023-2976", "CVE-2026-102554" ], "aliases": [ "GHSA-5mg8-w23w-74h3", "GHSA-7g45-4rm6-3mm3", "GHSA-mvr2-9pj6-7w5j", "GHSA-xxph-c9ww-hj94", "SNYK-JAVA-COMGOOGLEGUAVA-1015415" ], "description": "The old Guava is on your build machine and the application does not deploy any Guava at all. The four advisories are reported against 20.0, which the Maven plugin that builds the frontend resolves through a reflection library it uses to scan classes. What your application resolves is 31.1-jre, and at test scope, so it is not in the archive you deploy. Two of the four are about a temporary directory created with permissions that let other local users read it, and the other two are memory exhaustion when reading an untrusted serialised object. Nothing to do.", "affects": "<23", "match": "exact", "applicability": "not_affected" }, { "purl": "pkg:maven/com.google.guava/guava", "cves": [ "CVE-2026-102554" ], "aliases": [ "GHSA-xxph-c9ww-hj94" ], "description": "None unless your own code or an add-on deserializes untrusted Java-serialized data. This advisory is a denial of service that fires only when a serialized stream an attacker controls is read with ObjectInputStream, where Guava CompactHashMap, CompactHashSet or MapMakerInternalMap then allocate memory for a size the stream declares. On 24.4 and 24.7 Guava 33.7.1-jre is deployed, below the 33.7.2 fix, and it reaches the application through javaparser (under copilot and hilla) and selenium (under testbench); neither of those deserializes anything. A standard Vaadin application has no request path that reads untrusted serialized data, so nothing it runs reaches the vulnerable collections with attacker input. Code of your own, or an add-on, that deserializes untrusted data is the boundary; there the fix is to stop deserializing untrusted input, or to raise Guava to 33.7.2.", "affects": ">=24.4,<24.9", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/com.networknt/json-schema-validator", "cves": [ "CVE-2025-15104" ], "aliases": [], "description": "Your scanner matched the wrong product. CVE-2025-15104 is about Nu Html Checker (validator.nu), and the only CPE NVD gives it is validator:validator, a product name that dependency-check matches against json-schema-validator by keyword. No advisory database lists this CVE against com.networknt:json-schema-validator. Nothing has to be upgraded for it.", "affects": "*", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/flow-server", "cves": [ "CVE-2026-2742" ], "aliases": [ "GHSA-rjgh-wgc7-m37j" ], "description": "The published advisory says this artifact is fixed in a version it has never had. CVE-2026-2742 lets a request to a reserved framework path create a session without authenticating, and on the Vaadin 14 line the fix is flow-server 2.13.1, which Vaadin 14.14.1 and later resolve. The record scanners read says com.vaadin:flow-server is fixed in 14.14.1, a Vaadin platform number rather than a flow-server one, so a scanner comparing 2.13.8 against it concludes you are behind. You are not. Nothing to upgrade on this count.", "affects": ">=14.14.1,<14.15", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/flow-server", "cves": [ "CVE-2026-2742" ], "aliases": [ "GHSA-rjgh-wgc7-m37j" ], "description": "Your scanner is right that the advisory names your version and wrong that your version is affected, from 24.4.24 on. CVE-2026-2742 lets a request to a reserved framework path create a session without authenticating. The fix was backported to the 24.4 line as flow-server 24.4.18, which Vaadin 24.4.24 and later resolve, but the advisory still gives all of 24 below 24.9.8 one range, so every 24.4 release stays flagged. On 24.4.24 or later there is nothing to do. Below 24.4.24 the finding is real and you upgrade within 24.4, to 24.4.24 or later.", "affects": ">=24.4,<24.5", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/flow-server", "cves": [ "CVE-2026-2742" ], "aliases": [ "GHSA-rjgh-wgc7-m37j" ], "description": "Your scanner is right that the advisory names your version and wrong that your version is affected, from 24.7.16 on. CVE-2026-2742 lets a request to a reserved framework path create a session without authenticating. The fix was backported to the 24.7 line as flow-server 24.7.15, which Vaadin 24.7.16 and later resolve, but the advisory still gives all of 24 below 24.9.8 one range, so every 24.7 release stays flagged. On 24.7.16 or later there is nothing to do. Below 24.7.16 the finding is real and you upgrade within 24.7, to 24.7.16 or later.", "affects": ">=24.7,<24.8", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/vaadin", "cves": [ "CVE-2025-15022" ], "aliases": [ "GHSA-7wwv-79xw-rvvg" ], "description": "Your scanner is right that the advisory names your version and wrong that your version is affected, from 24.4.24 on. CVE-2025-15022 is a cross site scripting hole in the caption of a Spreadsheet context menu action, and the fix sanitises that caption. It was backported to 24.4 and is in 24.4.24 and later, but the advisory still gives all of 24 below 24.8.14 one range, so every 24.4 release stays flagged. On 24.4.24 or later there is nothing to do. Below it the finding is real and you upgrade within 24.4.", "affects": ">=24.4,<24.5", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/vaadin", "cves": [ "CVE-2025-15022" ], "aliases": [ "GHSA-7wwv-79xw-rvvg" ], "description": "Your scanner is right that the advisory names your version and wrong that your version is affected, from 24.7.15 on. CVE-2025-15022 is a cross site scripting hole in the caption of a Spreadsheet context menu action, and the fix sanitises that caption. It was backported to 24.7 and is in 24.7.15 and later, but the advisory still gives all of 24 below 24.8.14 one range, so every 24.7 release stays flagged. On 24.7.15 or later there is nothing to do. Below it the finding is real and you upgrade within 24.7.", "affects": ">=24.7,<24.8", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/vaadin", "cves": [ "CVE-2025-9467" ], "aliases": [ "GHSA-94g8-xv23-7656", "GHSA-c7v7-rqfm-f44j" ], "description": "Fixed on 24.4 from 24.4.24, and the advisory has not caught up. CVE-2025-9467 is a file upload whose validation can be bypassed, because the flag that interrupts a rejected upload was not read reliably by the thread doing the receiving. The fix makes that flag volatile and it is in 24.4.24 and later, but the published range runs from 24.0.0 to 24.7.6 in one piece, so every 24.4 release stays flagged. On 24.4.24 or later there is nothing to do. Below it the finding is real and you upgrade within 24.4.", "affects": ">=24.4,<24.5", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/vaadin", "cves": [ "CVE-2026-2742" ], "aliases": [ "GHSA-rjgh-wgc7-m37j" ], "description": "Your scanner is right that the advisory names your version and wrong that your version is affected, from 24.4.24 on. CVE-2026-2742 lets a request to a reserved framework path create a session without authenticating. The fix was backported to the 24.4 line as flow-server 24.4.18, which Vaadin 24.4.24 and later resolve, but the advisory still gives all of 24 below 24.9.8 one range, so every 24.4 release stays flagged. On 24.4.24 or later there is nothing to do. Below 24.4.24 the finding is real and you upgrade within 24.4, to 24.4.24 or later.", "affects": ">=24.4,<24.5", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/vaadin", "cves": [ "CVE-2026-2742" ], "aliases": [ "GHSA-rjgh-wgc7-m37j" ], "description": "Your scanner is right that the advisory names your version and wrong that your version is affected, from 24.7.16 on. CVE-2026-2742 lets a request to a reserved framework path create a session without authenticating. The fix was backported to the 24.7 line as flow-server 24.7.15, which Vaadin 24.7.16 and later resolve, but the advisory still gives all of 24 below 24.9.8 one range, so every 24.7 release stays flagged. On 24.7.16 or later there is nothing to do. Below 24.7.16 the finding is real and you upgrade within 24.7, to 24.7.16 or later.", "affects": ">=24.7,<24.8", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/vaadin-core", "cves": [ "CVE-2026-2741" ], "aliases": [], "description": "The check is missing on 24.4 and 24.7, and it is still nothing for a deployed application. The code unpacks the Node.js archive your build downloads when no Node is installed on the build machine, so it runs while you build and never in what you ship. Exploiting it needs a hostile archive, which means an attacker who already decides which Node.js your build unpacks and then runs, and at that point the archive itself is the problem. The fix is merged for both lines and not yet in a release.", "affects": ">=24.4,<24.9", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/com.vaadin/vaadin-core", "cves": [ "CVE-2026-2742" ], "aliases": [ "GHSA-rjgh-wgc7-m37j" ], "description": "Your scanner is right that the advisory names your version and wrong that your version is affected, from 24.4.24 on. CVE-2026-2742 lets a request to a reserved framework path create a session without authenticating. The fix was backported to the 24.4 line as flow-server 24.4.18, which Vaadin 24.4.24 and later resolve, but the advisory still gives all of 24 below 24.9.8 one range, so every 24.4 release stays flagged. On 24.4.24 or later there is nothing to do. Below 24.4.24 the finding is real and you upgrade within 24.4, to 24.4.24 or later.", "affects": ">=24.4,<24.5", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/vaadin-core", "cves": [ "CVE-2026-2742" ], "aliases": [ "GHSA-rjgh-wgc7-m37j" ], "description": "Your scanner is right that the advisory names your version and wrong that your version is affected, from 24.7.16 on. CVE-2026-2742 lets a request to a reserved framework path create a session without authenticating. The fix was backported to the 24.7 line as flow-server 24.7.15, which Vaadin 24.7.16 and later resolve, but the advisory still gives all of 24 below 24.9.8 one range, so every 24.7 release stays flagged. On 24.7.16 or later there is nothing to do. Below 24.7.16 the finding is real and you upgrade within 24.7, to 24.7.16 or later.", "affects": ">=24.7,<24.8", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/vaadin-spreadsheet-flow", "cves": [ "CVE-2025-15022" ], "aliases": [ "GHSA-7wwv-79xw-rvvg" ], "description": "Your scanner is right that the advisory names your version and wrong that your version is affected, from 24.4.24 on. CVE-2025-15022 is a cross site scripting hole in the caption of a Spreadsheet context menu action, and the fix sanitises that caption. It was backported to 24.4 and is in 24.4.24 and later, but the advisory still gives all of 24 below 24.8.14 one range, so every 24.4 release stays flagged. On 24.4.24 or later there is nothing to do. Below it the finding is real and you upgrade within 24.4.", "affects": ">=24.4,<24.5", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/vaadin-spreadsheet-flow", "cves": [ "CVE-2025-15022" ], "aliases": [ "GHSA-7wwv-79xw-rvvg" ], "description": "Your scanner is right that the advisory names your version and wrong that your version is affected, from 24.7.15 on. CVE-2025-15022 is a cross site scripting hole in the caption of a Spreadsheet context menu action, and the fix sanitises that caption. It was backported to 24.7 and is in 24.7.15 and later, but the advisory still gives all of 24 below 24.8.14 one range, so every 24.7 release stays flagged. On 24.7.15 or later there is nothing to do. Below it the finding is real and you upgrade within 24.7.", "affects": ">=24.7,<24.8", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/vaadin-swing-kit-flow", "cves": [ "CVE-2021-33604" ], "aliases": [], "description": "Your scanner has compared the Swing Kit version against the version range of a different artifact. CVE-2021-33604 is about the development mode handler of flow-server 2.0.0 to 2.6.1 and 3.0.0 to 6.0.9, that is Vaadin 14.0 to 14.6 and 15 to 19. vaadin-swing-kit-flow is not flow-server, but its own version numbers, 2.2.3 to 2.4.2 and 3.0.1, fall inside those ranges, so the match looks real. The range is open because the claim is about which artifact the advisory names, which no Swing Kit version changes. Nothing to upgrade for it.", "affects": "*", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/com.vaadin/vaadin-upload-flow", "cves": [ "CVE-2025-9467" ], "aliases": [ "GHSA-94g8-xv23-7656", "GHSA-c7v7-rqfm-f44j" ], "description": "Fixed on 24.4 from 24.4.24, and the advisory has not caught up. CVE-2025-9467 is a file upload whose validation can be bypassed, because the flag that interrupts a rejected upload was not read reliably by the thread doing the receiving. The fix makes that flag volatile and it is in 24.4.24 and later, but the published range runs from 24.0.0 to 24.7.6 in one piece, so every 24.4 release stays flagged. On 24.4.24 or later there is nothing to do. Below it the finding is real and you upgrade within 24.4.", "affects": ">=24.4,<24.5", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/commons-io/commons-io", "cves": [ "CVE-2024-47554" ], "aliases": [ "GHSA-78wr-2p64-hpwj" ], "description": "Two different copies, and the old one is on your build machine. The advisory is XmlStreamReader burning CPU on crafted input, and it is reported against commons-io 2.11.0, which is what the Maven plugin that builds the frontend resolves. Your application resolves 2.20.0, and the fix is 2.14.0, so the copy you deploy is well past it. Nothing to do.", "affects": ">=23,<24", "match": "exact", "applicability": "not_affected" }, { "purl": "pkg:maven/io.micrometer/micrometer-core", "cves": [ "CVE-2026-40984" ], "aliases": [ "GHSA-g3pr-3p32-fp23" ], "description": "This needs a Micrometer HTTP server instrumentation that you register yourself. The fix changes how the servlet and Jersey request tag providers of micrometer-core, and the Jetty 12 one, build the HTTP method tag. A plain Vaadin 24.7 application does not resolve micrometer-core at all. Control Center brings 1.14.14 with Actuator, but no class outside micrometer-core refers to those providers, so nothing in that stack creates one. Search your code for DefaultHttpJakartaServletRequestTagsProvider, the Jersey binder or micrometer-jetty12; if none is there, nothing reaches it.", "affects": ">=24.7,<24.8", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.netty/*", "cves": [ "CVE-2026-44891", "CVE-2026-55851", "CVE-2026-56817", "CVE-2026-56818", "CVE-2026-56819", "CVE-2026-56820", "CVE-2026-56821", "CVE-2026-56822", "CVE-2026-59900", "CVE-2026-59901", "CVE-2026-59902", "CVE-2026-59919", "CVE-2026-59920", "CVE-2026-73507", "CVE-2026-73508", "CVE-2026-75595", "CVE-2026-75596" ], "aliases": [ "GHSA-272m-gcwp-mpwg", "GHSA-2qj4-mmr9-4v2f", "GHSA-3g8r-4pfx-jmfh", "GHSA-4qhr-g3c6-fcfx", "GHSA-558v-64gr-wgg4", "GHSA-93wv-jw9v-4972", "GHSA-c4c3-7fpv-j4q5", "GHSA-c69g-56f8-xwqj", "GHSA-fccg-mwvh-qqg4", "GHSA-g7hg-vrcf-mvmr", "GHSA-mfg7-5gfp-c4w3", "GHSA-p9jm-q85p-7mcp", "GHSA-q6cq-mhr2-jmr5", "GHSA-v74w-7mr3-4qg3", "GHSA-vhch-2wf3-m8rp", "GHSA-wc96-39fc-566f", "GHSA-wh89-7897-x99h" ], "description": "Seventeen advisories that are real at the netty every Vaadin 24 line resolves today, 4.1.115.Final to 4.1.135.Final, each on its own artifact: netty-codec, codec-dns, codec-haproxy, codec-http2, codec-redis, codec-stomp, codec-xml, handler, handler-ssl-ocsp and transport-sctp. A production Vaadin application never runs it: Tomcat serves your requests, and netty is there because Copilot, a development mode tool, declares it. Nothing outside netty refers to the stomp, xml, redis, sctp or OCSP code at all. The rest runs only when your own code uses reactor-netty (WebClient, WebFlux), or on 24.9 and 24.10 when Control Center runs on Kubernetes, whose client reaches your API server through Vert.x on netty. Otherwise nothing calls it; if one applies, set the property below.", "affects": ">=24.4,<25", "match": "prefix", "applicability": "configuration" }, { "purl": "pkg:maven/io.netty/netty-codec", "cves": [ "CVE-2025-58057", "CVE-2026-42583" ], "aliases": [ "GHSA-3p8m-j85q-pgmj", "GHSA-mj4r-2hfc-f8p6" ], "description": "Real at the netty-codec your Spring Boot pins on Vaadin 24.4 and 24.7, and on 24.9 before 24.9.19 and 24.10 before 24.10.8; later 24.9 and 24.10 releases resolve 4.1.135.Final, which carries the fix. A production Vaadin application never runs it: Tomcat serves your requests, and netty is there because Copilot, a development mode tool, declares it. It runs when your own code uses reactor-netty (WebClient, WebFlux, reactive MongoDB, RSocket), and on 24.9 and 24.10 when Control Center runs on Kubernetes, where its Kubernetes client reaches your cluster's API server through Vert.x on netty. If none of that is you, nothing calls it; if one is, set the property below.", "affects": ">=24.4,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.netty/netty-codec-dns", "cves": [ "CVE-2026-42579" ], "aliases": [ "GHSA-cm33-6792-r9fm" ], "description": "Real at the netty-codec-dns your Spring Boot pins on Vaadin 24.4 and 24.7, and on 24.9 before 24.9.19 and 24.10 before 24.10.8; later 24.9 and 24.10 releases resolve 4.1.135.Final, which carries the fix. A production Vaadin application never runs it: Tomcat serves your requests, and netty is there because Copilot, a development mode tool, declares it. It runs when your own code uses reactor-netty (WebClient, WebFlux, reactive MongoDB, RSocket), and on 24.9 and 24.10 when Control Center runs on Kubernetes, where its Kubernetes client reaches your cluster's API server through Vert.x on netty. If none of that is you, nothing calls it; if one is, set the property below.", "affects": ">=24.4,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.netty/netty-codec-haproxy", "cves": [ "CVE-2026-44893", "CVE-2026-48059" ], "aliases": [ "GHSA-cc37-9q2j-3hfv", "GHSA-h2qv-fj59-j46j" ], "description": "Real at the netty-codec-haproxy your Spring Boot pins on Vaadin 24.4 and 24.7, and on 24.9 before 24.9.19 and 24.10 before 24.10.8; later 24.9 and 24.10 releases resolve 4.1.135.Final, which carries the fix. A production Vaadin application never runs it: Tomcat serves your requests, and netty is there because Copilot, a development mode tool, declares it. It runs only in a netty server that accepts the PROXY protocol, which you would have to start yourself with reactor-netty or Vert.x; the clients Copilot and Control Center use never decode it. If none of that is you, nothing calls it; if one is, set the property below.", "affects": ">=24.4,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.netty/netty-codec-http", "cves": [ "CVE-2026-55831", "CVE-2026-55833", "CVE-2026-56745", "CVE-2026-56746", "CVE-2026-59898", "CVE-2026-59899", "CVE-2026-59903", "CVE-2026-59921" ], "aliases": [ "GHSA-4mp9-239f-g9hg", "GHSA-6cqp-g7gg-8hr5", "GHSA-6jqx-86gh-f27w", "GHSA-8c42-7qj2-3j46", "GHSA-gcjf-9mgh-3p7g", "GHSA-jppx-w49h-x2qq", "GHSA-mvh2-crg5-v77c", "GHSA-q4f6-jm68-57ww" ], "description": "Real at the netty-codec-http every Vaadin 24 line resolves today, 4.1.115.Final to 4.1.135.Final; the fixes are in 4.1.136.Final and 4.1.137.Final. A production Vaadin application never runs it: Tomcat serves your requests, and netty is there because Copilot, a development mode tool, declares it. It runs when your own code uses reactor-netty (WebClient, WebFlux, reactive MongoDB, RSocket), and on 24.9 and 24.10 when Control Center runs on Kubernetes, where its Kubernetes client reaches your cluster's API server through Vert.x on netty. If none of that is you, nothing calls it; if one is, set the property below.", "affects": ">=24.4,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.netty/netty-codec-http", "cves": [ "CVE-2025-58056", "CVE-2025-67735", "CVE-2026-33870", "CVE-2026-41417", "CVE-2026-42580", "CVE-2026-42581", "CVE-2026-42584", "CVE-2026-42585", "CVE-2026-42587", "CVE-2026-50020" ], "aliases": [ "GHSA-38f8-5428-x5cv", "GHSA-57rv-r2g8-2cj3", "GHSA-84h7-rjj3-6jx4", "GHSA-f6hv-jmp6-3vwv", "GHSA-fghv-69vj-qj49", "GHSA-hvcg-qmg6-jm4c", "GHSA-m4cv-j2px-7723", "GHSA-pwqr-wmgm-9rr8", "GHSA-v8h7-rr48-vmmv", "GHSA-xxqh-mfjm-7mv9" ], "description": "Real at the netty-codec-http your Spring Boot pins on Vaadin 24.4 and 24.7, and on 24.9 before 24.9.19 and 24.10 before 24.10.8; later 24.9 and 24.10 releases resolve 4.1.135.Final, which carries the fix. A production Vaadin application never runs it: Tomcat serves your requests, and netty is there because Copilot, a development mode tool, declares it. It runs when your own code uses reactor-netty (WebClient, WebFlux, reactive MongoDB, RSocket), and on 24.9 and 24.10 when Control Center runs on Kubernetes, where its Kubernetes client reaches your cluster's API server through Vert.x on netty. If none of that is you, nothing calls it; if one is, set the property below.", "affects": ">=24.4,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.netty/netty-codec-http2", "cves": [ "CVE-2025-55163", "CVE-2026-33871", "CVE-2026-42587", "CVE-2026-47244", "CVE-2026-48043", "CVE-2026-50560" ], "aliases": [ "GHSA-563q-j3cm-6jxm", "GHSA-5x3r-wrvg-rp6q", "GHSA-c2gf-v879-257j", "GHSA-f6hv-jmp6-3vwv", "GHSA-prj3-ccx8-p6x4", "GHSA-w9fj-cfpg-grvv" ], "description": "Real at the netty-codec-http2 your Spring Boot pins on Vaadin 24.4 and 24.7, and on 24.9 before 24.9.19 and 24.10 before 24.10.8; later 24.9 and 24.10 releases resolve 4.1.135.Final, which carries the fix. A production Vaadin application never runs it: Tomcat serves your requests, and netty is there because Copilot, a development mode tool, declares it. It runs when your own code uses reactor-netty (WebClient, WebFlux, reactive MongoDB, RSocket), and on 24.9 and 24.10 when Control Center runs on Kubernetes, where its Kubernetes client reaches your cluster's API server through Vert.x on netty. If none of that is you, nothing calls it; if one is, set the property below.", "affects": ">=24.4,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.netty/netty-codec-memcache", "cves": [ "CVE-2025-24970", "CVE-2025-25193", "CVE-2025-55163", "CVE-2025-58056", "CVE-2025-58057", "CVE-2025-67735", "CVE-2026-33870", "CVE-2026-33871", "CVE-2026-41417", "CVE-2026-42578", "CVE-2026-42579", "CVE-2026-42580", "CVE-2026-42581", "CVE-2026-42583", "CVE-2026-42584", "CVE-2026-42585", "CVE-2026-42586", "CVE-2026-42587", "CVE-2026-44248", "CVE-2026-44249", "CVE-2026-44250", "CVE-2026-44890", "CVE-2026-44891", "CVE-2026-44893", "CVE-2026-45416", "CVE-2026-45536", "CVE-2026-45673", "CVE-2026-45674", "CVE-2026-46340", "CVE-2026-47244", "CVE-2026-47691", "CVE-2026-48006", "CVE-2026-48043", "CVE-2026-48059", "CVE-2026-50010", "CVE-2026-50011", "CVE-2026-50020", "CVE-2026-50560", "CVE-2026-55831", "CVE-2026-55833", "CVE-2026-55851", "CVE-2026-56745", "CVE-2026-56746", "CVE-2026-56817", "CVE-2026-56818", "CVE-2026-56819", "CVE-2026-56820", "CVE-2026-56821", "CVE-2026-56822", "CVE-2026-59898", "CVE-2026-59899", "CVE-2026-59900", "CVE-2026-59901", "CVE-2026-59902", "CVE-2026-59903", "CVE-2026-59919", "CVE-2026-59920", "CVE-2026-59921", "CVE-2026-62380", "CVE-2026-73507", "CVE-2026-73508", "CVE-2026-75595", "CVE-2026-75596", "CVE-2026-89044" ], "aliases": [ "GHSA-272m-gcwp-mpwg", "GHSA-2qj4-mmr9-4v2f", "GHSA-3244-j874-rhc2", "GHSA-389x-839f-4rhx", "GHSA-38f8-5428-x5cv", "GHSA-3g8r-4pfx-jmfh", "GHSA-3p8m-j85q-pgmj", "GHSA-3qp7-7mw8-wx86", "GHSA-45q3-82m4-75jr", "GHSA-4g8c-wm8x-jfhw", "GHSA-4mp9-239f-g9hg", "GHSA-4qhr-g3c6-fcfx", "GHSA-558v-64gr-wgg4", "GHSA-563q-j3cm-6jxm", "GHSA-57rv-r2g8-2cj3", "GHSA-5pvg-856g-cp85", "GHSA-5w86-c3rq-vjj7", "GHSA-5x3r-wrvg-rp6q", "GHSA-5xrh-qmmq-w6ch", "GHSA-676x-f7gg-47vc", "GHSA-6cqp-g7gg-8hr5", "GHSA-6ghj-frrj-jjj3", "GHSA-6jqx-86gh-f27w", "GHSA-6jv9-x5w9-2ccm", "GHSA-84h7-rjj3-6jx4", "GHSA-8c42-7qj2-3j46", "GHSA-93wv-jw9v-4972", "GHSA-c2gf-v879-257j", "GHSA-c4c3-7fpv-j4q5", "GHSA-c653-97m9-rcg9", "GHSA-c69g-56f8-xwqj", "GHSA-cc37-9q2j-3hfv", "GHSA-cm33-6792-r9fm", "GHSA-f6hv-jmp6-3vwv", "GHSA-fccg-mwvh-qqg4", "GHSA-fghv-69vj-qj49", "GHSA-g7hg-vrcf-mvmr", "GHSA-gcjf-9mgh-3p7g", "GHSA-h2qv-fj59-j46j", "GHSA-hvcg-qmg6-jm4c", "GHSA-jfg9-48mv-9qgx", "GHSA-jppx-w49h-x2qq", "GHSA-m4cv-j2px-7723", "GHSA-mfg7-5gfp-c4w3", "GHSA-mj4r-2hfc-f8p6", "GHSA-mvh2-crg5-v77c", "GHSA-p9jm-q85p-7mcp", "GHSA-prj3-ccx8-p6x4", "GHSA-pwqr-wmgm-9rr8", "GHSA-q4f6-jm68-57ww", "GHSA-q6cq-mhr2-jmr5", "GHSA-rgrr-p7gp-5xj7", "GHSA-v74w-7mr3-4qg3", "GHSA-v8h7-rr48-vmmv", "GHSA-vhch-2wf3-m8rp", "GHSA-w573-9ffj-6ff9", "GHSA-w9fj-cfpg-grvv", "GHSA-wc96-39fc-566f", "GHSA-wh89-7897-x99h", "GHSA-x4gw-5cx5-pgmh", "GHSA-xmv7-r254-6q78", "GHSA-xxqh-mfjm-7mv9" ], "description": "Your scanner has reported the whole netty family against one artifact of it. The CPE it matched, netty:netty, names the project and not the jar, so every netty advisory lands on every netty coordinate your application resolves. None of these 64 is about netty-codec-memcache: the advisory database answers nothing at all for this artifact at the versions a Vaadin 24.4 or 24.7 application resolves, and only the scanner that matches by CPE reports them. The advisories are real where they belong, and several of those artifacts are in a Vaadin application too, so this verdict answers for this coordinate and for no other.", "affects": ">=24.4,<25", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/io.netty/netty-codec-mqtt", "cves": [ "CVE-2025-24970", "CVE-2025-25193", "CVE-2025-55163", "CVE-2025-58056", "CVE-2025-58057", "CVE-2025-67735", "CVE-2026-33870", "CVE-2026-33871", "CVE-2026-41417", "CVE-2026-42578", "CVE-2026-42579", "CVE-2026-42580", "CVE-2026-42581", "CVE-2026-42583", "CVE-2026-42584", "CVE-2026-42585", "CVE-2026-42586", "CVE-2026-42587", "CVE-2026-44249", "CVE-2026-44250", "CVE-2026-44890", "CVE-2026-44891", "CVE-2026-44893", "CVE-2026-45416", "CVE-2026-45536", "CVE-2026-45673", "CVE-2026-45674", "CVE-2026-46340", "CVE-2026-47244", "CVE-2026-47691", "CVE-2026-48006", "CVE-2026-48043", "CVE-2026-48059", "CVE-2026-50010", "CVE-2026-50011", "CVE-2026-50020", "CVE-2026-50560", "CVE-2026-55831", "CVE-2026-55833", "CVE-2026-55851", "CVE-2026-56745", "CVE-2026-56746", "CVE-2026-56817", "CVE-2026-56818", "CVE-2026-56819", "CVE-2026-56820", "CVE-2026-56821", "CVE-2026-56822", "CVE-2026-59898", "CVE-2026-59899", "CVE-2026-59900", "CVE-2026-59901", "CVE-2026-59902", "CVE-2026-59903", "CVE-2026-59919", "CVE-2026-59920", "CVE-2026-59921", "CVE-2026-62380", "CVE-2026-73507", "CVE-2026-73508", "CVE-2026-75595", "CVE-2026-75596", "CVE-2026-89044" ], "aliases": [ "GHSA-272m-gcwp-mpwg", "GHSA-2qj4-mmr9-4v2f", "GHSA-3244-j874-rhc2", "GHSA-389x-839f-4rhx", "GHSA-38f8-5428-x5cv", "GHSA-3g8r-4pfx-jmfh", "GHSA-3p8m-j85q-pgmj", "GHSA-3qp7-7mw8-wx86", "GHSA-45q3-82m4-75jr", "GHSA-4g8c-wm8x-jfhw", "GHSA-4mp9-239f-g9hg", "GHSA-4qhr-g3c6-fcfx", "GHSA-558v-64gr-wgg4", "GHSA-563q-j3cm-6jxm", "GHSA-57rv-r2g8-2cj3", "GHSA-5pvg-856g-cp85", "GHSA-5w86-c3rq-vjj7", "GHSA-5x3r-wrvg-rp6q", "GHSA-5xrh-qmmq-w6ch", "GHSA-676x-f7gg-47vc", "GHSA-6cqp-g7gg-8hr5", "GHSA-6ghj-frrj-jjj3", "GHSA-6jqx-86gh-f27w", "GHSA-6jv9-x5w9-2ccm", "GHSA-84h7-rjj3-6jx4", "GHSA-8c42-7qj2-3j46", "GHSA-93wv-jw9v-4972", "GHSA-c2gf-v879-257j", "GHSA-c4c3-7fpv-j4q5", "GHSA-c653-97m9-rcg9", "GHSA-c69g-56f8-xwqj", "GHSA-cc37-9q2j-3hfv", "GHSA-cm33-6792-r9fm", "GHSA-f6hv-jmp6-3vwv", "GHSA-fccg-mwvh-qqg4", "GHSA-fghv-69vj-qj49", "GHSA-g7hg-vrcf-mvmr", "GHSA-gcjf-9mgh-3p7g", "GHSA-h2qv-fj59-j46j", "GHSA-hvcg-qmg6-jm4c", "GHSA-jppx-w49h-x2qq", "GHSA-m4cv-j2px-7723", "GHSA-mfg7-5gfp-c4w3", "GHSA-mj4r-2hfc-f8p6", "GHSA-mvh2-crg5-v77c", "GHSA-p9jm-q85p-7mcp", "GHSA-prj3-ccx8-p6x4", "GHSA-pwqr-wmgm-9rr8", "GHSA-q4f6-jm68-57ww", "GHSA-q6cq-mhr2-jmr5", "GHSA-rgrr-p7gp-5xj7", "GHSA-v74w-7mr3-4qg3", "GHSA-v8h7-rr48-vmmv", "GHSA-vhch-2wf3-m8rp", "GHSA-w573-9ffj-6ff9", "GHSA-w9fj-cfpg-grvv", "GHSA-wc96-39fc-566f", "GHSA-wh89-7897-x99h", "GHSA-x4gw-5cx5-pgmh", "GHSA-xmv7-r254-6q78", "GHSA-xxqh-mfjm-7mv9" ], "description": "Your scanner has reported the whole netty family against one artifact of it. The CPE it matched, netty:netty, names the project and not the jar, so every netty advisory lands on every netty coordinate your application resolves. None of these 63 is about netty-codec-mqtt: the advisory database answers nothing at all for this artifact at the versions a Vaadin 24.4 or 24.7 application resolves, and only the scanner that matches by CPE reports them. The advisories are real where they belong, and several of those artifacts are in a Vaadin application too, so this verdict answers for this coordinate and for no other. One advisory that three scanners agree on, CVE-2026-44248, is deliberately not in this list: it is reported for this artifact by osv-scanner and bomber as well, so it is answered on its own and not here.", "affects": ">=24.4,<25", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/io.netty/netty-codec-mqtt", "cves": [ "CVE-2026-44248" ], "aliases": [ "GHSA-jfg9-48mv-9qgx" ], "description": "Real at the netty-codec-mqtt your Spring Boot pins on Vaadin 24.4 and 24.7, and on 24.9 before 24.9.19 and 24.10 before 24.10.8; later 24.9 and 24.10 releases resolve 4.1.135.Final, which carries the fix. Nothing can call it. The jar is in your application because Copilot, a development mode tool, declares netty-all, and no class outside netty's own jars refers to the MQTT codec on any Vaadin 24 line: not Vaadin, not Spring, not reactor-netty, not Control Center. Only code you write against it could use it.", "affects": ">=24.4,<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/io.netty/netty-codec-redis", "cves": [ "CVE-2026-42586", "CVE-2026-44250", "CVE-2026-44890", "CVE-2026-48006", "CVE-2026-50011" ], "aliases": [ "GHSA-3244-j874-rhc2", "GHSA-5w86-c3rq-vjj7", "GHSA-6ghj-frrj-jjj3", "GHSA-6jv9-x5w9-2ccm", "GHSA-rgrr-p7gp-5xj7" ], "description": "Real at the netty-codec-redis your Spring Boot pins on Vaadin 24.4 and 24.7, and on 24.9 before 24.9.19 and 24.10 before 24.10.8; later 24.9 and 24.10 releases resolve 4.1.135.Final, which carries the fix. Nothing can call it. The jar is in your application because Copilot, a development mode tool, declares netty-all, and no class outside netty's own jars refers to the Redis codec on any Vaadin 24 line: not Vaadin, not Spring, not reactor-netty, not Control Center. Only code you write against it could use it.", "affects": ">=24.4,<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/io.netty/netty-codec-smtp", "cves": [ "CVE-2025-59419" ], "aliases": [ "GHSA-jq43-27x9-3v86" ], "description": "Real at the netty-codec-smtp your Spring Boot pins on Vaadin 24.4, on 24.7 before 24.7.16 and on 24.9 before 24.9.4; later releases resolve 4.1.128.Final or newer, which carries the fix. Nothing can call it. The jar is in your application because Copilot, a development mode tool, declares netty-all, and no class outside netty's own jars refers to the SMTP codec on any Vaadin 24 line: not Vaadin, not Spring, not reactor-netty, not Control Center. Only code you write against it could use it.", "affects": ">=24.4,<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/io.netty/netty-common", "cves": [ "CVE-2025-25193" ], "aliases": [ "GHSA-389x-839f-4rhx" ], "description": "Real on Vaadin 24.4 and on 24.7.0 and 24.7.1, which resolve netty-common below 4.1.118.Final; 24.7.2 and later, 24.9 and 24.10 resolve a fixed version. It needs three things at once: Windows, a local account able to create C:\\etc\\os-release, and code that initialises netty's PlatformDependent. A production Vaadin application does not initialise it: booted on 24.4.26 it loads five netty buffer classes during Spring Boot's condition checks and never PlatformDependent. Your own reactor-netty use, a WebClient for example, would.", "affects": ">=24.4,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.netty/netty-handler", "cves": [ "CVE-2025-24970", "CVE-2026-44249", "CVE-2026-45416", "CVE-2026-50010" ], "aliases": [ "GHSA-3qp7-7mw8-wx86", "GHSA-4g8c-wm8x-jfhw", "GHSA-c653-97m9-rcg9", "GHSA-x4gw-5cx5-pgmh" ], "description": "Real at the netty-handler your Spring Boot pins on Vaadin 24.4 and 24.7, and on 24.9 before 24.9.19 and 24.10 before 24.10.8; later 24.9 and 24.10 releases resolve 4.1.135.Final, which carries the fix. A production Vaadin application never runs it: Tomcat serves your requests, and netty is there because Copilot, a development mode tool, declares it. It runs when your own code uses reactor-netty (WebClient, WebFlux, reactive MongoDB, RSocket), and on 24.9 and 24.10 when Control Center runs on Kubernetes, where its Kubernetes client reaches your cluster's API server through Vert.x on netty. If none of that is you, nothing calls it; if one is, set the property below.", "affects": ">=24.4,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.netty/netty-handler-proxy", "cves": [ "CVE-2026-42578" ], "aliases": [ "GHSA-45q3-82m4-75jr" ], "description": "Real at the netty-handler-proxy your Spring Boot pins on Vaadin 24.4 and 24.7, and on 24.9 before 24.9.19 and 24.10 before 24.10.8; later 24.9 and 24.10 releases resolve 4.1.135.Final, which carries the fix. A production Vaadin application never runs it: Tomcat serves your requests, and netty is there because Copilot, a development mode tool, declares it. It runs when your own code uses reactor-netty (WebClient, WebFlux, reactive MongoDB, RSocket), and on 24.9 and 24.10 when Control Center runs on Kubernetes, where its Kubernetes client reaches your cluster's API server through Vert.x on netty. If none of that is you, nothing calls it; if one is, set the property below.", "affects": ">=24.4,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.netty/netty-resolver-dns", "cves": [ "CVE-2026-45673", "CVE-2026-45674", "CVE-2026-47691" ], "aliases": [ "GHSA-5pvg-856g-cp85", "GHSA-676x-f7gg-47vc", "GHSA-xmv7-r254-6q78" ], "description": "Real at the netty-resolver-dns your Spring Boot pins on Vaadin 24.4 and 24.7, and on 24.9 before 24.9.19 and 24.10 before 24.10.8; later 24.9 and 24.10 releases resolve 4.1.135.Final, which carries the fix. A production Vaadin application never runs it: Tomcat serves your requests, and netty is there because Copilot, a development mode tool, declares it. It runs when your own code uses reactor-netty (WebClient, WebFlux, reactive MongoDB, RSocket), and on 24.9 and 24.10 when Control Center runs on Kubernetes, where its Kubernetes client reaches your cluster's API server through Vert.x on netty. If none of that is you, nothing calls it; if one is, set the property below.", "affects": ">=24.4,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.netty/netty-transport", "cves": [ "CVE-2025-24970", "CVE-2025-25193", "CVE-2025-55163", "CVE-2025-58056", "CVE-2025-58057", "CVE-2025-67735", "CVE-2026-33870", "CVE-2026-33871", "CVE-2026-41417", "CVE-2026-42578", "CVE-2026-42579", "CVE-2026-42580", "CVE-2026-42581", "CVE-2026-42583", "CVE-2026-42584", "CVE-2026-42585", "CVE-2026-42586", "CVE-2026-42587", "CVE-2026-44248", "CVE-2026-44249", "CVE-2026-44250", "CVE-2026-44890", "CVE-2026-44891", "CVE-2026-44893", "CVE-2026-45416", "CVE-2026-45536", "CVE-2026-45673", "CVE-2026-45674", "CVE-2026-46340", "CVE-2026-47244", "CVE-2026-47691", "CVE-2026-48006", "CVE-2026-48043", "CVE-2026-48059", "CVE-2026-50010", "CVE-2026-50011", "CVE-2026-50020", "CVE-2026-50560", "CVE-2026-55831", "CVE-2026-55833", "CVE-2026-55851", "CVE-2026-56745", "CVE-2026-56746", "CVE-2026-56817", "CVE-2026-56818", "CVE-2026-56819", "CVE-2026-56820", "CVE-2026-56821", "CVE-2026-56822", "CVE-2026-59898", "CVE-2026-59899", "CVE-2026-59900", "CVE-2026-59901", "CVE-2026-59902", "CVE-2026-59903", "CVE-2026-59919", "CVE-2026-59920", "CVE-2026-59921", "CVE-2026-62380", "CVE-2026-73507", "CVE-2026-73508", "CVE-2026-75595", "CVE-2026-75596", "CVE-2026-89044" ], "aliases": [ "GHSA-272m-gcwp-mpwg", "GHSA-2qj4-mmr9-4v2f", "GHSA-3244-j874-rhc2", "GHSA-389x-839f-4rhx", "GHSA-38f8-5428-x5cv", "GHSA-3g8r-4pfx-jmfh", "GHSA-3p8m-j85q-pgmj", "GHSA-3qp7-7mw8-wx86", "GHSA-45q3-82m4-75jr", "GHSA-4g8c-wm8x-jfhw", "GHSA-4mp9-239f-g9hg", "GHSA-4qhr-g3c6-fcfx", "GHSA-558v-64gr-wgg4", "GHSA-563q-j3cm-6jxm", "GHSA-57rv-r2g8-2cj3", "GHSA-5pvg-856g-cp85", "GHSA-5w86-c3rq-vjj7", "GHSA-5x3r-wrvg-rp6q", "GHSA-5xrh-qmmq-w6ch", "GHSA-676x-f7gg-47vc", "GHSA-6cqp-g7gg-8hr5", "GHSA-6ghj-frrj-jjj3", "GHSA-6jqx-86gh-f27w", "GHSA-6jv9-x5w9-2ccm", "GHSA-84h7-rjj3-6jx4", "GHSA-8c42-7qj2-3j46", "GHSA-93wv-jw9v-4972", "GHSA-c2gf-v879-257j", "GHSA-c4c3-7fpv-j4q5", "GHSA-c653-97m9-rcg9", "GHSA-c69g-56f8-xwqj", "GHSA-cc37-9q2j-3hfv", "GHSA-cm33-6792-r9fm", "GHSA-f6hv-jmp6-3vwv", "GHSA-fccg-mwvh-qqg4", "GHSA-fghv-69vj-qj49", "GHSA-g7hg-vrcf-mvmr", "GHSA-gcjf-9mgh-3p7g", "GHSA-h2qv-fj59-j46j", "GHSA-hvcg-qmg6-jm4c", "GHSA-jfg9-48mv-9qgx", "GHSA-jppx-w49h-x2qq", "GHSA-m4cv-j2px-7723", "GHSA-mfg7-5gfp-c4w3", "GHSA-mj4r-2hfc-f8p6", "GHSA-mvh2-crg5-v77c", "GHSA-p9jm-q85p-7mcp", "GHSA-prj3-ccx8-p6x4", "GHSA-pwqr-wmgm-9rr8", "GHSA-q4f6-jm68-57ww", "GHSA-q6cq-mhr2-jmr5", "GHSA-rgrr-p7gp-5xj7", "GHSA-v74w-7mr3-4qg3", "GHSA-v8h7-rr48-vmmv", "GHSA-vhch-2wf3-m8rp", "GHSA-w573-9ffj-6ff9", "GHSA-w9fj-cfpg-grvv", "GHSA-wc96-39fc-566f", "GHSA-wh89-7897-x99h", "GHSA-x4gw-5cx5-pgmh", "GHSA-xmv7-r254-6q78", "GHSA-xxqh-mfjm-7mv9" ], "description": "Your scanner has reported the whole netty family against one artifact of it. The CPE it matched, netty:netty, names the project and not the jar, so every netty advisory lands on every netty coordinate your application resolves. None of these 64 is about netty-transport: the advisory database answers nothing at all for this artifact at the versions a Vaadin 24.4 or 24.7 application resolves, and only the scanner that matches by CPE reports them. The advisories are real where they belong, and several of those artifacts are in a Vaadin application too, so this verdict answers for this coordinate and for no other.", "affects": ">=24.4,<25", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/io.netty/netty-transport-native-epoll", "cves": [ "CVE-2026-45536" ], "aliases": [ "GHSA-w573-9ffj-6ff9" ], "description": "Real at the netty-transport-native-epoll your Spring Boot pins on Vaadin 24.4 and 24.7, and on 24.9 before 24.9.19 and 24.10 before 24.10.8; later 24.9 and 24.10 releases resolve 4.1.135.Final, which carries the fix. Nothing can reach it. The advisory is about a Unix domain socket that receives file descriptors, which netty does only when DomainSocketReadMode.FILE_DESCRIPTORS is set, and no class outside netty's own jars refers to that setting on any Vaadin 24 line. reactor-netty and Vert.x can open domain sockets, but neither switches that mode on, and nothing in Vaadin opens one.", "affects": ">=24.4,<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/io.netty/netty-transport-native-kqueue", "cves": [ "CVE-2026-45536" ], "aliases": [ "GHSA-w573-9ffj-6ff9" ], "description": "Real at the netty-transport-native-kqueue your Spring Boot pins on Vaadin 24.4 and 24.7, and on 24.9 before 24.9.19 and 24.10 before 24.10.8; later 24.9 and 24.10 releases resolve 4.1.135.Final, which carries the fix. Nothing can reach it. The advisory is about a Unix domain socket that receives file descriptors, which netty does only when DomainSocketReadMode.FILE_DESCRIPTORS is set, and no class outside netty's own jars refers to that setting on any Vaadin 24 line. reactor-netty and Vert.x can open domain sockets, but neither switches that mode on, and nothing in Vaadin opens one.", "affects": ">=24.4,<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/io.netty/netty-transport-sctp", "cves": [ "CVE-2026-46340" ], "aliases": [ "GHSA-5xrh-qmmq-w6ch" ], "description": "Real at the netty-transport-sctp your Spring Boot pins on Vaadin 24.4 and 24.7, and on 24.9 before 24.9.19 and 24.10 before 24.10.8; later 24.9 and 24.10 releases resolve 4.1.135.Final, which carries the fix. Nothing can call it. The jar is in your application because Copilot, a development mode tool, declares netty-all, and no class outside netty's own jars refers to the SCTP transport on any Vaadin 24 line: not Vaadin, not Spring, not reactor-netty, not Control Center. Only code you write against it could use it.", "affects": ">=24.4,<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/io.opentelemetry/*", "cves": [ "CVE-2026-24051", "CVE-2026-39882", "CVE-2026-39883", "CVE-2026-41178", "CVE-2026-54285" ], "aliases": [ "GHSA-8988-4f7v-96qf" ], "description": "Your scanner has matched the wrong product. The CPE it used, opentelemetry:opentelemetry, names the project rather than a package and carries the platform each record is about: CVE-2026-54285 is an advisory of opentelemetry-js on node.js, and the other four are advisories of the Go implementation. None is about a Java artifact, but the Java libraries share the product name, so each lands on every io.opentelemetry jar your application resolves. The range is open because the claim is about which implementation the records name, which no Java version changes. Nothing to upgrade for these.", "affects": "*", "match": "prefix", "applicability": "false_positive" }, { "purl": "pkg:maven/io.opentelemetry/opentelemetry-api", "cves": [ "CVE-2026-118259", "GHSA-ccrj-gw8r-854m" ], "aliases": [], "description": "The parser is in the jar and nothing in a Vaadin application hands it an incoming header. From 25.3, opentelemetry-api 1.62.0 arrives through TestBench, whose Selenium client only adds trace context to the requests it sends, and Observability Kit no longer uses OpenTelemetry or an agent. The advisory needs incoming tracestate headers to reach W3CTraceContextPropagator.extract, which happens only if you add tracing of your own: Spring Boot OpenTelemetry tracing, the OpenTelemetry Java agent, or code that extracts trace context from requests.", "affects": ">=25.3", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.projectreactor.netty/reactor-netty", "cves": [ "CVE-2026-41715" ], "aliases": [ "GHSA-pfc9-2cqg-9wq6" ], "description": "Real at the reactor-netty your Spring Boot pins, 1.1.24 on Vaadin 24.4 and 1.2.13 on 24.7, and it is a client defect: a request that follows a redirect from https to http can resend its credentials. No Vaadin code makes such a request in a production application. Copilot, the development mode tool, uses the client to reach the Copilot service. It applies to you when your own code uses WebClient or the reactor-netty HttpClient with credentials and redirects.", "affects": ">=24.4,<24.9", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.projectreactor.netty/reactor-netty-core", "cves": [ "CVE-2026-47874" ], "aliases": [], "description": "The advisory is about a server your application does not start. Pipelined HTTP/1.1 requests make the Reactor Netty HTTP server hold on to memory, and a Vaadin application is served by the embedded Tomcat its Spring Boot starts, not by Reactor Netty. The library is here because Copilot, the development mode tool, uses it as an HTTP client, and a client does not accept pipelined requests from anybody. Outside Reactor Netty, only Spring's reactive web server support refers to the server class, and Spring Boot builds that server only for a reactive application, which a Vaadin application is not.", "affects": ">=24.9,<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/io.projectreactor.netty/reactor-netty-core", "cves": [ "CVE-2026-47874" ], "aliases": [], "description": "The advisory is about a server your application does not start. Pipelined HTTP/1.1 requests make the Reactor Netty HTTP server hold on to memory, and a Vaadin application is served by the embedded Tomcat its Spring Boot starts, not by Reactor Netty. The library is here because Copilot, the development mode tool, uses it as an HTTP client, and a client does not accept pipelined requests from anybody. Outside Reactor Netty, only Spring's reactive web server support refers to the server class, and Spring Boot builds that server only for a reactive application, which a Vaadin application is not.", "affects": ">=24.4,<24.9", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/io.projectreactor.netty/reactor-netty-http", "cves": [ "CVE-2025-22227" ], "aliases": [ "GHSA-4q2v-9p7v-3v22" ], "description": "Real at reactor-netty-http 1.1.24, which Spring Boot 3.2.12 pins on Vaadin 24.4, and it is a client defect: a request that follows a chain of redirects can leak its credentials to another host. No Vaadin code makes such a request in a production application. Copilot, the development mode tool, uses the client to reach the Copilot service. It applies to you when your own code uses WebClient or the reactor-netty HttpClient with credentials and redirects.", "affects": ">=24.4,<24.5", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/io.projectreactor.netty/reactor-netty-quic", "cves": [ "CVE-2023-34054", "CVE-2023-34062" ], "aliases": [], "description": "Your scanner has matched the wrong artifact. Both advisories, from 2023, are about the Reactor Netty HTTP server in reactor-netty-core and reactor-netty-http before 1.1.13 and 1.0.39. reactor-netty-quic is a separate artifact whose first release, 1.0.0-M4, was published in June 2025, and the advisory database lists neither id against it at any version. Nothing has to be upgraded for it.", "affects": "*", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/io.vertx/vertx-core", "cves": [ "CVE-2026-102460", "CVE-2026-102461", "CVE-2026-102462", "CVE-2026-102463", "CVE-2026-102464", "CVE-2026-102465", "CVE-2026-102466", "CVE-2026-102469", "CVE-2026-102471", "CVE-2026-102477", "CVE-2026-103223", "CVE-2026-103224" ], "aliases": [], "description": "Your scanner has matched the product and not the module. The CPE it used, eclipse:vert.x, names the whole project, and Eclipse published a batch of advisories on the same day that all read \"in Eclipse Vert.x versions [4.0.0, 4.5.34]\", so every one of them lands on every Vert.x jar your application resolves. An application with Control Center resolves two, vertx-core and vertx-web-client, and each of these advisories is filed against a module it does not resolve: vertx-web, vertx-json-schema, vertx-sql-client, vertx-mqtt, vertx-redis-client, vertx-mail-client and vertx-grpc. The advisories are real where they belong and none of those modules is here. The thirteenth advisory of that batch, CVE-2026-102467, does name vertx-core and is answered on its own.", "affects": ">=24.9,<25", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/io.vertx/vertx-core", "cves": [ "CVE-2026-102467" ], "aliases": [], "description": "Real in vertx-core 4.5.34, and the path that carries it is never opened. The advisory needs a compressed WebSocket frame, and compression is negotiated: Vert.x 4.5.34 offers neither per message nor per frame compression by default, and the fabric8 Kubernetes client that owns this connection never turns either on, so no frame is ever decompressed. Vert.x is here only with Control Center, as the HTTP client fabric8 uses to reach your cluster's Kubernetes API server, not as a server facing your users. Note that fabric8 raises the frame and message size caps to Integer.MAX_VALUE; the safety is the negotiation, nothing else.", "affects": ">=24.9,<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/io.vertx/vertx-web-client", "cves": [ "CVE-2026-102460", "CVE-2026-102461", "CVE-2026-102462", "CVE-2026-102463", "CVE-2026-102464", "CVE-2026-102465", "CVE-2026-102466", "CVE-2026-102467", "CVE-2026-102469", "CVE-2026-102471", "CVE-2026-102477", "CVE-2026-103223", "CVE-2026-103224" ], "aliases": [], "description": "Your scanner has matched the product and not the module. The CPE it used, eclipse:vert.x, names the whole project, and Eclipse published a batch of advisories on the same day that all read \"in Eclipse Vert.x versions [4.0.0, 4.5.34]\", so every one of them lands on every Vert.x jar your application resolves. An application with Control Center resolves two, vertx-core and vertx-web-client, and each of these advisories is filed against a module it does not resolve: vertx-web, vertx-json-schema, vertx-sql-client, vertx-mqtt, vertx-redis-client, vertx-mail-client and vertx-grpc. The advisories are real where they belong and none of those modules is here. The thirteenth, CVE-2026-102467, names io.vertx:vertx-core in its own text, so it is not about this artifact either; it is answered against vertx-core.", "affects": ">=24.9,<25", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/me.friwi/jcef-api", "cves": [ "CVE-2024-9410" ], "aliases": [], "description": "Your scanner has matched the wrong product. CVE-2024-9410 is a server side request forgery in the Sentry configuration of Ada.cx, a hosted customer service product, and jcef-api is the Java binding of the Chromium Embedded Framework that Swing Kit brings. They have nothing in common, so no version of jcef-api is affected. Nothing to upgrade for it.", "affects": "*", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/me.friwi/jcef-api", "cves": [ "CVE-2024-21639", "CVE-2024-21640" ], "aliases": [], "description": "Your scanner has flagged a Chromium Embedded Framework that already carries the fix. These two advisories are out of bounds reads in the off screen rendering code of CEF, reachable by a compromised GPU process, and they are fixed from CEF 120.2.3 and 121.2.6. Swing Kit on Vaadin 24.4.16 and later brings CEF 127.3.1 or 135.0.20. The scanner cannot compare the version string jcef-api carries with the date NVD uses as its bound, so it reports every version. Nothing to upgrade for these.", "affects": ">=24.4.16,<24.5", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/me.friwi/jcef-api", "cves": [ "CVE-2024-21639", "CVE-2024-21640" ], "aliases": [], "description": "Your scanner has flagged a Chromium Embedded Framework that already carries the fix. These two advisories are out of bounds reads in the off screen rendering code of CEF, reachable by a compromised GPU process, and they are fixed from CEF 120.2.3 and 121.2.6. Swing Kit on Vaadin 24.7 brings CEF 127.3.1 or 135.0.20. The scanner cannot compare the version string jcef-api carries with the date NVD uses as its bound, so it reports every version. Nothing to upgrade for these.", "affects": ">=24.7,<24.8", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/me.friwi/jcef-api", "cves": [ "CVE-2024-21639", "CVE-2024-21640" ], "aliases": [], "description": "Your scanner has flagged a Chromium Embedded Framework that already carries the fix. These two advisories are out of bounds reads in the off screen rendering code of CEF, reachable by a compromised GPU process, and they are fixed from CEF 120.2.3 and 121.2.6. Swing Kit on Vaadin 24.9 and later brings CEF 127.3.1 or 135.0.20. The scanner cannot compare the version string jcef-api carries with the date NVD uses as its bound, so it reports every version. Nothing to upgrade for these.", "affects": ">=24.9", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.apache.commons/commons-compress", "cves": [ "CVE-2021-35515", "CVE-2021-35516", "CVE-2021-35517", "CVE-2021-36090", "CVE-2024-25710" ], "aliases": [ "GHSA-4g9r-vxhx-9pgx", "GHSA-7hfm-57qf-j43q", "GHSA-crv7-7245-f45f", "GHSA-mc84-pj99-q6hh", "GHSA-xqfj-vm6h-2x34" ], "description": "Two different copies of this library, and the old one is on your build machine. The five advisories are about reading a crafted archive: an infinite loop on a corrupt DUMP file and four cases of a length field that does not match the data. They are reported against commons-compress 1.5, which is what the Maven plugin that builds the frontend resolves, through the Node tooling it uses to unpack what it downloads. Your application resolves 1.26.1, a different and newer copy, and every one of the five is fixed below that. Nothing to do: the archive the build unpacks is the Node distribution, not anything a user sends you.", "affects": "<23", "match": "exact", "applicability": "not_affected" }, { "purl": "pkg:maven/org.apache.commons/commons-lang3", "cves": [ "CVE-2025-48924" ], "aliases": [ "GHSA-j288-q9x7-2f5v" ], "description": "One method of this library overflows the stack on a very long argument, and nothing in Vaadin calls it. ClassUtils.getClass recurses on a class name, so a name thousands of characters long throws a StackOverflowError. Its only callers on the classpath are in Commons Text and Commons Configuration: their ${const:...} lookups and the bean declarations of Commons Configuration. You reach them only by feeding that interpolation, or such a configuration, text somebody else wrote. Spring Boot 3.5 picks the version, 3.17.0, and Vaadin does not.", "affects": ">=24.9,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.apache.commons/commons-lang3", "cves": [ "CVE-2025-48924" ], "aliases": [ "GHSA-j288-q9x7-2f5v" ], "description": "One method of this library overflows the stack on a very long argument, and nothing in Vaadin calls it. ClassUtils.getClass recurses on a class name, so a name thousands of characters long throws a StackOverflowError. Its only callers on the classpath are in Commons Text and Commons Configuration: their ${const:...} lookups and the bean declarations of Commons Configuration. You reach them only by feeding that interpolation, or such a configuration, text somebody else wrote. Spring Boot picks the version, not Vaadin: 3.2 pins 3.13.0 and 3.4 pins 3.17.0. The 3.14.0 a scanner may also report on 24.4.25 and 24.4.26 is on the classpath of the Maven plugin, on your build machine only.", "affects": ">=24.4,<24.9", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.apache.commons/commons-lang3", "cves": [ "CVE-2025-48924" ], "aliases": [ "GHSA-j288-q9x7-2f5v" ], "description": "The method this advisory is about has no caller outside the library on these series. ClassUtils.getClass recurses on a class name, so a name thousands of characters long throws a StackOverflowError. On Vaadin 14 and 23 every class that refers to ClassUtils is inside commons-lang3 itself: Commons Text and Commons Configuration, which call it on the 24 series, are not on these classpaths. The version, 3.12.0, is the one Spring Boot 2.7 pins.", "affects": "<24", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/org.apache.httpcomponents/httpclient", "cves": [ "CVE-2020-13956" ], "aliases": [ "GHSA-7r82-7xv7-xcpj" ], "description": "Same shape as the other two build findings: the version reported is the one the Maven plugin resolves, 4.5.1, and your application resolves 4.5.14, which is past the fix. The advisory is about HttpClient parsing a URI that does not follow the spec and ending up treating it as a different authority. Nothing to do.", "affects": "<23", "match": "exact", "applicability": "not_affected" }, { "purl": "pkg:maven/org.apache.logging.log4j/log4j-api", "cves": [ "CVE-2026-49844" ], "aliases": [ "GHSA-qv9r-c865-cp47" ], "description": "About the jar you have, and about a path nothing in a Vaadin application takes. When a MapMessage holds a NaN or an infinity, MapMessage.asJson emits that bare token and the result is not valid JSON. The advisory names its own two conditions: you have to be using the message resolver of JsonTemplateLayout, or another layout that calls MapMessage.asJson, and you have to log a non finite float through a MapMessage. A Spring Boot application logs through Logback, so there is no Log4j layout at all. You would reach this by swapping in spring-boot-starter-log4j2, configuring that layout, and logging a MapMessage yourself. The damage if you do is a log line a JSON parser rejects.", "affects": "<24", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.apache.logging.log4j/log4j-api", "cves": [ "CVE-2026-49844" ], "aliases": [ "GHSA-qv9r-c865-cp47" ], "description": "About a path nothing in a Vaadin application takes. When a MapMessage holds NaN or an infinity, MapMessage.asJson emits that bare token and the result is not valid JSON. The advisory names two conditions: a layout that calls asJson, such as the message resolver of JsonTemplateLayout, and a non finite number logged through a MapMessage. Spring Boot logs through Logback, and neither log4j-core nor JsonTemplateLayout is on the classpath of any 24 series. You would reach this only by switching to spring-boot-starter-log4j2, configuring that layout and logging a MapMessage yourself.", "affects": ">=24,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.apache.logging.log4j/log4j-api", "cves": [ "CVE-2026-34477", "CVE-2026-34479" ], "aliases": [], "description": "Both of these are about Log4j artifacts your application does not have. The scanner matched the CPE apache:log4j, which is the project rather than the jar. CVE-2026-34477 is incomplete hostname verification in log4j-core, and CVE-2026-34479 is XML escaping in the Log4j 1 bridge, log4j-1.2-api. A Spring Boot application logs through Logback: what it resolves of Log4j is the API and the log4j-to-slf4j bridge, which forwards every call to slf4j, and neither of the two artifacts these advisories name is on the classpath at all. The same answer already covers the 24 series, where the resolved version is different.", "affects": "<24", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.apache.logging.log4j/log4j-api", "cves": [ "CVE-2026-34477", "CVE-2026-34479" ], "aliases": [], "description": "Both of these are about Log4j artifacts your application does not have. The scanner matched the CPE apache:log4j, which is the project rather than the jar. CVE-2026-34477 is incomplete hostname verification in log4j-core, and CVE-2026-34479 is XML escaping in the Log4j 1 bridge, log4j-1.2-api. A Spring Boot application logs through Logback: what it resolves of Log4j is the API and the log4j-to-slf4j bridge, and neither artifact these advisories name is on the classpath of any 24 series.", "affects": ">=24,<25", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.apache.poi/poi", "cves": [ "CVE-2025-31672" ], "aliases": [ "GHSA-gmg8-593g-7mv3" ], "description": "Right advisory, wrong jar. This is about reading OOXML files, the zip based formats like xlsx and docx, and the advisory is filed against poi-ooxml. The artifact your scanner matched is poi, the core library for the older binary formats. Your application does carry poi-ooxml, through the Spreadsheet component, so read it there: it has its own verdict.", "affects": ">=23,<24", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.apache.poi/poi", "cves": [ "CVE-2025-31672" ], "aliases": [ "GHSA-gmg8-593g-7mv3" ], "description": "Right advisory, wrong jar. This is about reading OOXML files, the zip based formats like xlsx and docx, and the advisory is filed against poi-ooxml. The artifact your scanner matched is poi, the core library for the older binary formats, and the parsing the advisory describes is not in it. Your application does carry poi-ooxml, through the Spreadsheet component, so read it there: it has its own verdict.", "affects": ">=24.4,<24.7", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.apache.tomcat.embed/tomcat-embed-core", "cves": [ "CVE-2026-66299" ], "aliases": [], "description": "The vulnerable code is the WebSocket chat example, which lives in the examples web application of the full Tomcat distribution. Vaadin ships the embedded container, and that artifact does not contain it. Tomcat says the same thing in its own advisory: whoever removed the examples web application is not affected, and here there is nothing to remove.", "affects": "*", "match": "exact", "applicability": "not_affected" }, { "purl": "pkg:maven/org.apache.tomcat.embed/tomcat-embed-core", "cves": [ "CVE-2026-29145" ], "aliases": [], "description": "This one is about client certificate authentication through Tomcat Native, and a Vaadin application does not use either by default. When CLIENT_CERT authentication runs with soft fail disabled, a failure that should reject the request does not always do so. It needs two things you have to set up: a connector that uses Tomcat Native, which is a separate library you install on the machine, and CLIENT_CERT configured on it. The embedded Tomcat a Spring Boot starter brings uses the Java connector and no native library. If you have configured mutual TLS through Tomcat Native, this is yours to act on.", "affects": ">=24.4,<24.8", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.apache.tomcat.embed/tomcat-embed-core", "cves": [ "CVE-2026-29145" ], "aliases": [], "description": "Not in range on the 25 series. The advisory ends its Tomcat 11 range before 11.0.20, and every 25.2, 25.3 and 25.4 release resolves 11.0.22 or 11.0.24, so the Tomcat you carry already has the fix. A scanner reports it because it matched the Tomcat product name rather than the range.", "affects": ">=25", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.apache.tomcat.embed/tomcat-embed-core", "cves": [ "CVE-2026-29145" ], "aliases": [], "description": "This one is about client certificate authentication through Tomcat Native, and a Vaadin application does not use either by default. When CLIENT_CERT authentication runs with soft fail disabled, a failure that should reject the request does not always do so. It needs two things you have to set up: a connector that uses Tomcat Native, which is a separate library you install on the machine, and CLIENT_CERT configured on it. The embedded Tomcat a Spring Boot starter brings uses the Java connector and no native library. If you have configured mutual TLS through Tomcat Native, this is yours to act on.", "affects": "<24", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.apache.tomcat.embed/tomcat-embed-core", "cves": [ "CVE-2026-29145" ], "aliases": [], "description": "On 24.9 and 24.10 this depends on the release, and then on Tomcat Native. 24.9.0 to 24.9.13 and 24.10.0 resolve Tomcat 10.1.44 to 10.1.52, inside the advisory's range, which ends before 10.1.53; from 24.9.14 and 24.10.1 they resolve 10.1.53 or later and are past it. Even in range it needs CLIENT_CERT authentication with soft fail disabled on a connector backed by Tomcat Native, a separate library you install, and the embedded Tomcat of the Spring Boot starter uses the Java connector.", "affects": ">=24.9,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.apache.tomcat.embed/tomcat-embed-core", "cves": [ "CVE-2026-34500" ], "aliases": [], "description": "This one is about a Tomcat artifact your application does not have. The FFM connector, OpenSSL reached through the Java Foreign Function and Memory API, ships as org.apache.tomcat:tomcat-coyote-ffm, and the advisory database files CVE-2026-34500 against that artifact only, for 10.1.22 to 10.1.53 among others. 24.4 and 24.7 resolve tomcat-embed-core 10.1.33 and 10.1.50, which hold no FFM class, and do not resolve tomcat-coyote-ffm. If your own pom adds tomcat-coyote-ffm, the finding is real for that artifact and 10.1.54 or later fixes it.", "affects": ">=24.4,<24.8", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.apache.tomcat.embed/tomcat-embed-core", "cves": [ "CVE-2024-54677", "CVE-2026-29146" ], "aliases": [], "description": "The code these two are about is not in the artifact your application has. CVE-2024-54677 is in the examples web application of the full Tomcat distribution, and Vaadin ships the embedded container, which has no examples to remove. CVE-2026-29146 is a padding oracle in the EncryptInterceptor of Tomcat clustering, which lives in tomcat-tribes: the embedded core has no class under org/apache/catalina/tribes/ at all. Nothing has to be upgraded for either.", "affects": ">=24.4,<24.8", "match": "exact", "applicability": "not_affected" }, { "purl": "pkg:maven/org.apache.tomcat.embed/tomcat-embed-core", "cves": [ "CVE-2024-54677", "CVE-2026-29146" ], "aliases": [], "description": "The code these two are about is not in the artifact your application has. CVE-2024-54677 is in the examples web application of the full Tomcat distribution, and Vaadin ships the embedded container, which has no examples to remove. CVE-2026-29146 is a padding oracle in the EncryptInterceptor of Tomcat's clustering, which lives in tomcat-tribes: the embedded core has no class under org/apache/catalina/tribes/ at all. Nothing has to be upgraded for either.", "affects": "<24", "match": "exact", "applicability": "not_affected" }, { "purl": "pkg:maven/org.apache.tomcat.embed/tomcat-embed-core", "cves": [ "CVE-2024-23672" ], "aliases": [ "BIT-tomcat-2024-23672", "GHSA-v682-8vv8-vpwr" ], "description": "Right advisory, wrong jar. This is about Tomcat's WebSocket implementation, which the advisory database files against tomcat-websocket and tomcat-embed-websocket, and the embedded core carries no class under org/apache/tomcat/websocket/. Read it on tomcat-embed-websocket, which your application does have: it arrives with the Spring Boot starter beside this one, and the same property moves both.", "affects": "<24", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.bitbucket.b_c/jose4j", "cves": [ "CVE-2024-29371" ], "aliases": [ "GHSA-3677-xxcr-wjqv" ], "description": "The library is on your classpath and the part of it this advisory is about is never entered. The attack is a JSON Web Encryption token with an enormous compression ratio: whoever decrypts it spends memory and time unpacking it. jose4j reaches a Vaadin application through Web Push, which uses it to sign the token that identifies your server to the push service. Signing produces a token, it does not consume one, and nothing on the classpath outside jose4j itself refers to its JWE machinery, so there is no path by which a token from outside gets decrypted.", "affects": ">=24.4,<24.7", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/org.codehaus.jackson/jackson-mapper-asl", "cves": [ "CVE-2019-10172", "CVE-2019-10202" ], "aliases": [ "GHSA-c27h-mcmw-48hv", "GHSA-r6j9-8759-g62w" ], "description": "Not in what you deploy. jackson-mapper-asl is Jackson 1, out of maintenance since 2013, and on Vaadin 14 it arrives only on the classpath of the Vaadin Maven plugin, through the frontend-plugin-core library that installs Node.js during the build. Your application does not resolve it, so nothing you ship contains it.", "affects": "<23", "match": "exact", "applicability": "not_affected" }, { "purl": "pkg:maven/org.codehaus.plexus/plexus-utils", "cves": [ "CVE-2022-4244", "CVE-2022-4245" ], "aliases": [ "GHSA-g6ph-x5wf-g337", "GHSA-jcwr-x25h-x5fh" ], "description": "These reach the machine that builds a 23.6 application, not the application. plexus-utils 3.0.22 is on the classpath of the Vaadin Maven plugin, and it is inside the affected range, below 3.0.24. One advisory is a directory traversal when an archive is unpacked and the other is XML injection through a comment written unescaped, and nothing on that classpath calls either the unpacking class or the XML comment writer. Your deployed application does not contain plexus-utils at all.", "affects": ">=23.6,<24", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/org.codehaus.plexus/plexus-utils", "cves": [ "CVE-2025-67030" ], "aliases": [ "GHSA-6fmv-xxpf-w3cw" ], "description": "This reaches the machine that builds a 14.14 application, not the application, and nothing there calls the affected code. The Vaadin Maven plugin brought plexus-utils 3.0.22 through frontend-plugin-core up to 14.14.7. The advisory is about Expand.extractFile unpacking an archive, and nothing on the plugin classpath calls Expand. From 14.14.8 the plugin resolves plexus-utils 3.6.2, outside the affected range.", "affects": ">=14.14,<14.15", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/org.codehaus.plexus/plexus-utils", "cves": [ "CVE-2025-67030" ], "aliases": [ "GHSA-6fmv-xxpf-w3cw" ], "description": "This reaches the machine that builds a 23.6 application, not the application, and nothing there calls the affected code. The Vaadin Maven plugin brings plexus-utils 3.0.22, which is in the affected range, and no 23.6 release has moved it. The advisory is about Expand.extractFile unpacking an archive, and nothing on the plugin classpath calls Expand.", "affects": ">=23.6,<24", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/org.codehaus.plexus/plexus-utils", "cves": [ "CVE-2025-67030" ], "aliases": [ "GHSA-6fmv-xxpf-w3cw" ], "description": "On the 24 series this reaches the application as well as the build, and nothing calls the affected code in either. App Sec Kit brings plexus-utils 3.4.2 into the application through maven-artifact on 24.4, 24.7, 24.9 up to 24.9.14 and 24.10.0 and 24.10.1, and the Vaadin Maven plugin brings 4.0.0 on 24.4, 24.7, 24.9 and 24.10 up to 24.10.11. Both are in the affected range. The advisory is about Expand.extractFile unpacking an archive, and nothing on either classpath calls Expand.", "affects": ">=24.4,<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/org.codehaus.plexus/plexus-utils", "cves": [ "CVE-2025-67030" ], "aliases": [ "GHSA-6fmv-xxpf-w3cw" ], "description": "This reaches the machine that builds the application, not the application, and nothing there calls the affected code. The Vaadin Maven plugin brought plexus-utils 4.0.0 on 25.2 up to 25.2.10 and on 25.3.0 and 25.3.1; the newest, 25.2.12 and 25.3.3, resolve 3.6.2, outside the affected range. The advisory is about Expand.extractFile unpacking an archive, and nothing on the plugin classpath calls Expand.", "affects": ">=25.2,<25.4", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/org.cyclonedx/cyclonedx-core-java", "cves": [ "CVE-2025-64518" ], "aliases": [ "GHSA-6fhj-vr9j-g45r" ], "description": "This is about the XML half of a library that App Sec Kit uses for its JSON half. The advisory is an XML external entity hole in the validator that checks an XML bill of materials. App Sec Kit reads the bill of materials your build produced as JSON: the only classes of this library it refers to are the JSON parser, the model and the parse exception, and nothing else on the classpath touches the XML side. 24.9 and later resolve 11.0.1, which is fixed.", "affects": ">=24.4,<24.9", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/org.jetbrains.kotlin/kotlin-reflect", "cves": [ "CVE-2026-53914" ], "aliases": [], "description": "Your scanner has matched the wrong artifact. The advisory is unsafe deserialization of the incremental cache of KAPT, the annotation processing plugin of the Kotlin build tooling, and the advisory database names only org.jetbrains.kotlin:kotlin-gradle-plugin. The CPE jetbrains:kotlin covers every artifact JetBrains publishes under that name, so the scanner reported it on kotlin-reflect, which does not contain that code. The range is open because no version of kotlin-reflect carries it. Nothing to upgrade for it.", "affects": "*", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.jetbrains.kotlin/kotlin-stdlib", "cves": [ "CVE-2020-29582" ], "aliases": [], "description": "The functions this advisory is about are still in the kotlin-stdlib the 24 series resolve, and nothing calls them. The advisory is createTempDir and createTempFile in kotlin.io creating files a local user can read. Kotlin 1.4.21 deprecated them and Kotlin 2.1.0 made them an error, which is why the advisory database says before 1.4.21 and NVD says before 2.1.0. The 24 series resolve 1.9.25, where they still exist, and no library on the classpath calls them. The 25 series resolve 2.3.21, outside both ranges.", "affects": ">=24.4,<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/org.jetbrains.kotlin/kotlin-stdlib", "cves": [ "CVE-2026-53914" ], "aliases": [], "description": "Your scanner has matched the wrong artifact. The advisory is unsafe deserialization of the incremental cache of KAPT, the annotation processing plugin of the Kotlin build tooling, and the advisory database names only org.jetbrains.kotlin:kotlin-gradle-plugin. The CPE jetbrains:kotlin covers every artifact JetBrains publishes under that name, so the scanner reported it on kotlin-stdlib, which does not contain that code. The range is open because no version of kotlin-stdlib carries it. Nothing to upgrade for it.", "affects": "*", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.jetbrains.kotlin/kotlin-stdlib-common", "cves": [ "CVE-2026-53914" ], "aliases": [], "description": "Your scanner has matched the wrong artifact. The advisory is unsafe deserialization of the incremental cache of KAPT, the annotation processing plugin of the Kotlin build tooling, and the advisory database names only org.jetbrains.kotlin:kotlin-gradle-plugin. The CPE jetbrains:kotlin covers every artifact JetBrains publishes under that name, so the scanner reported it on kotlin-stdlib-common, which does not contain that code. The range is open because no version of kotlin-stdlib-common carries it. Nothing to upgrade for it.", "affects": "*", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.jetbrains.kotlin/kotlin-stdlib-jdk7", "cves": [ "CVE-2026-53914" ], "aliases": [], "description": "Your scanner has matched the wrong artifact. The advisory is unsafe deserialization of the incremental cache of KAPT, the annotation processing plugin of the Kotlin build tooling, and the advisory database names only org.jetbrains.kotlin:kotlin-gradle-plugin. The CPE jetbrains:kotlin covers every artifact JetBrains publishes under that name, so the scanner reported it on kotlin-stdlib-jdk7, which does not contain that code. The range is open because no version of kotlin-stdlib-jdk7 carries it. Nothing to upgrade for it.", "affects": "*", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.jsoup/jsoup", "cves": [ "CVE-2026-71497", "CVE-2026-75140" ], "aliases": [ "GHSA-65r4-943x-97jj", "GHSA-pmhh-3w7g-xqp8" ], "description": "Vaadin does use jsoup, and neither of the two parts these advisories are about. CVE-2026-71497 is the Cleaner mis-parsing a malformed tag name when a custom Safelist permits raw text elements, so it needs you to be sanitising with a Safelist of your own. CVE-2026-75140 is the XML tree builder copying the inherited namespace map on every start element, so it needs you to be parsing XML with jsoup. Vaadin calls Jsoup.parse on HTML it wrote itself, the bootstrap page and the template files, and neither the Cleaner nor the XML builder is referenced by anything outside the library.", "affects": "<24", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot", "cves": [ "CVE-2025-22235" ], "aliases": [ "GHSA-rc42-6c7j-7h5r" ], "description": "The class this advisory is about is not in the jar it was reported on, and a Vaadin 24.4 application does not resolve the jar that holds it. EndpointRequest lives in spring-boot-actuator-autoconfigure, and 24.4.26 resolves no Actuator artifact. If you added Actuator yourself, the advisory applies only when all four of its conditions hold: you use Spring Security, a security rule uses EndpointRequest.to(), the endpoint it names is disabled or not exposed, and your application serves /null and needs it protected.", "affects": ">=24.4,<24.5", "match": "exact", "applicability": "not_affected" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot", "cves": [ "CVE-2026-40973" ], "aliases": [ "GHSA-wwpq-f5c3-7hvx" ], "description": "This needs two things you would have to arrange: an attacker with a local account on the machine your application runs on, and server.servlet.session.persistent set to true. Spring Boot's ApplicationTemp picks a predictable directory under the system temporary directory without checking who owns it, and on the classpath of a Vaadin 14 or 23 application the only class that uses it is SessionStoreDirectory, which stores persisted HTTP sessions. Persistence is off by default. If you have turned it on, read the workaround.", "affects": "<24", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot", "cves": [ "CVE-2025-22235" ], "aliases": [ "GHSA-rc42-6c7j-7h5r" ], "description": "The class this advisory is about is not on your classpath. EndpointRequest is an Actuator API and lives in spring-boot-actuator, which a Vaadin application does not pull in, and the advisory's own conditions ask you to have called EndpointRequest.to() in a Spring Security chain. Vaadin never calls it. If you have added Actuator yourself and your security configuration uses EndpointRequest.to() against an endpoint that is disabled or not exposed, and your application serves a path /null that needs protecting, then read the advisory on spring-boot-actuator, because those four conditions are the whole of it.", "affects": "<24", "match": "exact", "applicability": "not_affected" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot", "cves": [ "CVE-2026-40975", "CVE-2026-40977" ], "aliases": [], "description": "These two are about classes of the spring-boot jar your application carries, and both need something you would have to do. CVE-2026-40975 says values of ${random.value} are not strong enough to be secrets, so it reaches you only if your own properties put ${random.value} where a key or password goes. CVE-2026-40977 needs ApplicationPidFileWriter, which Spring Boot does not register for you, plus a local user who can write where the PID file goes. Check your properties for ${random.value} and your code and spring.factories for ApplicationPidFileWriter.", "affects": "<24", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot", "cves": [ "CVE-2026-22733", "CVE-2026-40972", "CVE-2026-40974", "CVE-2026-41001" ], "aliases": [ "GHSA-56v8-86gj-66jp", "GHSA-ggg2-9786-hwc8", "GHSA-mgvc-8q2h-5pgc" ], "description": "Four Spring Boot advisories landed on this jar because the scanner matched the product name vmware:spring_boot, which every Spring Boot artifact carries. None of the four is about code in spring-boot: CVE-2026-22733 is about the Actuator CloudFoundry path, CVE-2026-40972 about DevTools, and CVE-2026-40974 and CVE-2026-41001 about the Cassandra and Artemis auto-configuration in spring-boot-autoconfigure. CVE-2026-40972 and CVE-2026-41001 are answered on those coordinates. CVE-2026-40975 and CVE-2026-40977, which are about this jar, have their own verdict.", "affects": "<24", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot*", "cves": [ "CVE-2026-22731", "CVE-2026-22733" ], "aliases": [ "GHSA-8hfc-fq58-r658", "GHSA-mgvc-8q2h-5pgc" ], "description": "Both need Actuator and one of your own endpoints that requires authentication placed under a path Actuator has taken: a health group additional path for CVE-2026-22731, or /cloudfoundryapplication for CVE-2026-22733. A plain Vaadin 24.7 starter does not bring Actuator; Control Center does. Even then the bypass needs that path collision, which you can check in your own configuration. Spring fixed both in Spring Boot 3.5.12. The 3.4 fix, 3.4.15, is sold under commercial support only, so 3.4.13, which 24.7.17 declares, is the last free release of that line.", "affects": ">=24.7,<24.8", "match": "prefix", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot*", "cves": [ "CVE-2026-40972" ], "aliases": [ "GHSA-56v8-86gj-66jp" ], "description": "This one is about the DevTools remote debugging channel, which is off unless you set its secret. DevTools only runs in development, it is stripped from a repackaged application, and its remote support does nothing at all until spring.devtools.remote.secret is set. When it is set, the server compares the secret in a way that leaks its length through timing, and an attacker on the same network can eventually recover it and upload classes. If you have ever enabled remote DevTools against a deployed application, that is the configuration the advisory describes and it should not be deployed at all.", "affects": ">=24.7,<24.8", "match": "prefix", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot*", "cves": [ "CVE-2026-40974", "CVE-2026-40992", "CVE-2026-41001" ], "aliases": [ "GHSA-ggg2-9786-hwc8" ], "description": "These three are about auto-configurations that switch on only when their library is on your classpath, and a Vaadin 24.7 application resolves none of the three libraries. CVE-2026-40974 is the Cassandra SSL auto-configuration skipping hostname verification, CVE-2026-40992 is the mail auto-configuration skipping it, and CVE-2026-41001 is the embedded Artemis broker using a fixed, predictable data directory that another local user can create first. If you have added the Cassandra driver, a mail starter or embedded Artemis yourself, the workaround says what to set.", "affects": ">=24.7,<24.8", "match": "prefix", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot*", "cves": [ "CVE-2026-40973", "CVE-2026-40975", "CVE-2026-40977" ], "aliases": [ "GHSA-wwpq-f5c3-7hvx" ], "description": "These three need something you have to turn on, and all three also need a local attacker on the same host. CVE-2026-40973 needs server.servlet.session.persistent set to true, which defaults to false, before a local attacker who controls the ApplicationTemp directory can read persisted sessions. CVE-2026-40977 needs ApplicationPidFileWriter registered, which Spring Boot does not register for you. CVE-2026-40975 is not a flaw in code that runs by itself at all: it says that the value of the ${random.value} property placeholder is not strong enough to be used as a secret, so it reaches you only if your own configuration uses it that way. Check your properties for ${random.value} behind anything that acts as a key or a password.", "affects": ">=24.7,<24.8", "match": "prefix", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot-autoconfigure", "cves": [ "CVE-2026-41001" ], "aliases": [ "GHSA-ggg2-9786-hwc8" ], "description": "This is about an embedded message broker your application does not run. Spring Boot's ArtemisEmbeddedConfigurationFactory gives the embedded Artemis broker a fixed path for its data directory when none is configured, so on a shared host another local user can get there first. The autoconfiguration that uses it only runs when Artemis itself is on the classpath, and a Vaadin application does not bring it: you would have to add spring-boot-starter-artemis and run the broker embedded. If you do, configure the data directory explicitly.", "affects": "<24", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot-devtools", "cves": [ "CVE-2022-31691" ], "aliases": [], "description": "Your scanner has matched the wrong product. This advisory is about Spring Tools 4 for Eclipse and the Spring Boot Tools extension for VSCode, which are editor tooling, and the dependency it was matched against is spring-boot-devtools, a different artifact that no editor ships. Nothing in a Vaadin application is affected, and nothing has to be upgraded for it. The same answer already covers the 25 series and this one says it for 14 and 23, where the resolved version is different.", "affects": "<24", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot-devtools", "cves": [ "CVE-2022-31691" ], "aliases": [], "description": "Your scanner has matched the wrong product. This advisory is about Spring Tools 4 for Eclipse and the Spring Boot Tools extension for VSCode, which are editor tooling, and the dependency it was matched against is spring-boot-devtools, a different artifact that no editor ships. Nothing in a Vaadin application is affected, and nothing has to be upgraded for it.", "affects": ">=25.0", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot-devtools", "cves": [ "CVE-2026-40972" ], "aliases": [ "GHSA-56v8-86gj-66jp" ], "description": "This is the one advisory on this jar that is really about this jar, and it is about a feature nobody has switched on. Remote DevTools lets a developer push changes to an application running somewhere else, and the secret it compares is where the timing attack is. The whole server, the filter and the comparison exist only when the property spring.devtools.remote.secret is set, so an application that has never set it has no remote endpoint to attack. Check your own configuration for that property and for the SPRING_DEVTOOLS_REMOTE_SECRET environment variable. If you do use remote DevTools, it belongs on a development machine and never on anything reachable from outside.", "affects": "<24", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.boot/spring-boot-devtools", "cves": [ "CVE-2026-22733", "CVE-2026-40973", "CVE-2026-40974", "CVE-2026-40975", "CVE-2026-40977", "CVE-2026-41001" ], "aliases": [ "GHSA-ggg2-9786-hwc8", "GHSA-mgvc-8q2h-5pgc", "GHSA-wwpq-f5c3-7hvx" ], "description": "Six Spring Boot advisories landed on this jar because the scanner matched the product name vmware:spring_boot, which every Spring Boot artifact carries. None of the six is about code in spring-boot-devtools. CVE-2026-22733 is about the Actuator CloudFoundry path, CVE-2026-40974 and CVE-2026-41001 about the Cassandra and Artemis auto-configuration in spring-boot-autoconfigure, and CVE-2026-40973, CVE-2026-40975 and CVE-2026-40977 about classes of the spring-boot jar. The ones about code your application carries are answered on those coordinates.", "affects": "<24", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.springframework.cloud/spring-cloud-commons", "cves": [ "CVE-2026-59284" ], "aliases": [], "description": "This needs the writable /actuator/env endpoint, which is off unless you switch it on. Spring Cloud lets a POST to /actuator/env set any property, with no allow list of keys. spring-cloud-commons and spring-cloud-context arrive only with Control Center, and Control Center also brings Spring Boot Actuator, so the endpoint code is on your classpath. It is registered only when you set management.endpoint.env.post.enabled and expose the env endpoint over HTTP; Spring Boot exposes only health by default, and Control Center sets neither property.", "affects": ">=24.9,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.cloud/spring-cloud-context", "cves": [ "CVE-2026-59284" ], "aliases": [], "description": "This needs the writable /actuator/env endpoint, which is off unless you switch it on. Spring Cloud lets a POST to /actuator/env set any property, with no allow list of keys. spring-cloud-commons and spring-cloud-context arrive only with Control Center, and Control Center also brings Spring Boot Actuator, so the endpoint code is on your classpath. It is registered only when you set management.endpoint.env.post.enabled and expose the env endpoint over HTTP; Spring Boot exposes only health by default, and Control Center sets neither property.", "affects": ">=24.9,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.data/spring-data-commons", "cves": [ "CVE-2026-41695", "CVE-2026-41711", "CVE-2026-41716", "CVE-2026-41721" ], "aliases": [ "GHSA-5m4m-73w9-8433", "GHSA-5vpf-xvv7-c8vh", "GHSA-88fw-v6x4-3f58", "GHSA-9fw2-h3hf-293r" ], "description": "Spring Data Commons is in your deployed application on 24.4 and 24.7, and all four need your application to accept sort, paging, property path or projection input over HTTP. vaadin-spring-boot-starter brings it through Hilla at compile scope: 3.2.12 on 24.4, 3.4.13 on 24.7, both in range. What hands request input to Spring Data is a Spring MVC controller of yours taking Pageable, Sort or a @ProjectedPayload type, or a Hilla endpoint taking Pageable. A Flow application with neither does not reach this code.", "affects": ">=24.4,<24.9", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.security/spring-security*", "cves": [ "CVE-2026-22748" ], "aliases": [ "GHSA-cvc6-q2cp-2xhw" ], "description": "In range on 24.4 after all, and it needs a JWT decoder your own code builds. Spring lists Spring Security 6.1.0 to 6.3.14 as affected, and 24.4.26 resolves 6.2.8. The flaw is that NimbusJwtDecoder.withIssuerLocation adds no issuer validation unless you call setJwtValidator. Spring Boot's resource server auto-configuration does call it, with an issuer validator, and nothing else on a Vaadin 24.4 classpath builds such a decoder. Search your code for withIssuerLocation; if it is there without setJwtValidator, read the workaround.", "affects": ">=24.4,<24.5", "match": "prefix", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.security/spring-security*", "cves": [ "CVE-2026-40988", "CVE-2026-41003", "CVE-2026-41694" ], "aliases": [], "description": "These three are about SAML, and the artifact that carries it is not on your classpath. All three are filed against spring-security-saml2-service-provider, a separate Spring Security artifact that an application adds when it federates through SAML. A Vaadin 24.7 application does not resolve it, not through the starter and not through Control Center. If you have added it yourself, read the advisories as yours and move Spring Security to 6.5.11.", "affects": ">=24.7,<24.8", "match": "prefix", "applicability": "not_affected" }, { "purl": "pkg:maven/org.springframework.security/spring-security*", "cves": [ "CVE-2026-22751" ], "aliases": [ "GHSA-x2wq-9x2f-fhj7" ], "description": "This needs One-Time Token login configured with JdbcOneTimeTokenService, which your application has to set up itself. It is in the Spring Security 6.4.13 that 24.7 resolves, and nothing on a Vaadin 24.7 classpath creates a JdbcOneTimeTokenService for you. Search your code for JdbcOneTimeTokenService: if it is not there, this does not apply.", "affects": ">=24.7,<24.8", "match": "prefix", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.security/spring-security*", "cves": [ "CVE-2026-22748" ], "aliases": [ "GHSA-cvc6-q2cp-2xhw" ], "description": "In range on 24.7, and it needs a JWT decoder your own code builds. The flaw is that NimbusJwtDecoder.withIssuerLocation adds no issuer validation unless you call setJwtValidator. Spring Boot's resource server auto-configuration does call it, with an issuer validator, and nothing else on a Vaadin 24.7 classpath builds such a decoder, Control Center and SSO Kit included. Search your code for withIssuerLocation; if it is there without setJwtValidator, read the workaround.", "affects": ">=24.7,<24.8", "match": "prefix", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.security/spring-security*", "cves": [ "CVE-2026-41706", "CVE-2026-47838" ], "aliases": [ "GHSA-293q-567p-wmwq", "GHSA-x2r2-rvhq-2mqv" ], "description": "Both need a feature you switch on. CVE-2026-47838 is in SubjectDnX509PrincipalExtractor, used only when your security configuration enables X.509 client certificate login with x509(); Spring calls the fix defense in depth, since that flow trusts an upstream that already validated the certificate. CVE-2026-41706 is in CookieRequestCache, which Vaadin installs only when you turn on stateless authentication with setStatelessAuthentication in VaadinWebSecurity, and it also needs an attacker able to set the REDIRECT_URI cookie. Check your configuration for x509(), setStatelessAuthentication and CookieRequestCache.", "affects": ">=24.4,<24.5", "match": "prefix", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.security/spring-security*", "cves": [ "CVE-2026-41706", "CVE-2026-47838" ], "aliases": [ "GHSA-293q-567p-wmwq", "GHSA-x2r2-rvhq-2mqv" ], "description": "Both need a feature you switch on. CVE-2026-47838 is in SubjectDnX509PrincipalExtractor, used only when your security configuration enables X.509 client certificate login with x509(); Spring calls the fix defense in depth, since that flow trusts an upstream that already validated the certificate. CVE-2026-41706 is in CookieRequestCache, which Vaadin installs only when you turn on stateless authentication with setStatelessAuthentication in VaadinWebSecurity, and it also needs an attacker able to set the REDIRECT_URI cookie. Check your configuration for x509(), setStatelessAuthentication and CookieRequestCache.", "affects": ">=24.7,<24.8", "match": "prefix", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.security/spring-security-core", "cves": [ "CVE-2026-41707", "CVE-2026-47841", "CVE-2026-47842", "CVE-2026-59270" ], "aliases": [], "description": "Four Spring Security advisories filed under the product name vmware:spring_security, about code in other Spring Security jars. DPoP proof replay is in spring-security-oauth2-jose, the WebAuthn bypass in spring-security-web, the AES encryptor in spring-security-crypto, and the embedded UnboundID LDAP server in spring-security-ldap, which a Vaadin application does not resolve. The versions are in range, 6.4.13 on 24.7 and 6.5 on 24.9 and 24.10; the coordinate is what is wrong. CVE-2026-59276, which is about this jar, has its own verdict.", "affects": ">=24.7,<25", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.springframework.security/spring-security-core", "cves": [ "CVE-2026-59276" ], "aliases": [], "description": "This one is really about this jar, and about a class nothing creates for you. Of the five components the advisory names as comparing secrets with String.equals, the one in spring-security-core is KeyBasedPersistenceTokenService. Spring Security does not register it, Spring Boot does not auto configure it and no Vaadin artifact mentions it, on 24.7 as on 24.9 and 24.10. Search your sources for KeyBasedPersistenceTokenService; if it is not there, nothing in this jar is exposed by this advisory.", "affects": ">=24.7,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework.security/spring-security-oauth2-core", "cves": [ "CVE-2026-41707", "CVE-2026-47841", "CVE-2026-47842", "CVE-2026-59270", "CVE-2026-59276" ], "aliases": [], "description": "Five Spring Security advisories landed on this jar because the scanner matched the product name vmware:spring_security, which every artifact of the project carries. None of the five is about this one: DPoP proof replay, WebAuthn user verification, the AES encryptor, the embedded UnboundID LDAP server and a set of non constant time comparisons are all in other Spring Security jars. The versions are in range, 6.4.13 on 24.7 and 6.5 on 24.9 and 24.10; the coordinate is what is wrong.", "affects": ">=24.7,<25", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.springframework/spring-core", "cves": [ "CVE-2026-47883", "CVE-2026-47887" ], "aliases": [], "description": "Two open redirects that need a component only your own configuration registers. Your scanner reports them on spring-core; CVE-2026-47883 is about UrlHandlerFilter in spring-web and CVE-2026-47887 about UrlFilenameViewController in spring-webmvc. Nothing on a Vaadin 24 classpath refers to either class except the class itself. CVE-2026-47883 starts at 6.2.0, so 24.4 is below it; 24.7 and later are in range, as every 24 series is for CVE-2026-47887.", "affects": ">=24,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework/spring-core", "cves": [ "CVE-2026-22735", "CVE-2026-22737", "CVE-2026-22740", "CVE-2026-22741", "CVE-2026-22745", "CVE-2026-41838", "CVE-2026-41839", "CVE-2026-41840", "CVE-2026-41841", "CVE-2026-41842", "CVE-2026-41843", "CVE-2026-41844", "CVE-2026-41845", "CVE-2026-41846", "CVE-2026-41850", "CVE-2026-41851", "CVE-2026-41852", "CVE-2026-41853", "CVE-2026-41855", "CVE-2026-47884", "CVE-2026-47885", "CVE-2026-47888", "CVE-2026-47889", "CVE-2026-47890", "CVE-2026-47891", "CVE-2026-47892", "CVE-2026-47893", "CVE-2026-59280" ], "aliases": [ "GHSA-3chg-m5w7-qfv5", "GHSA-4773-3jfm-qmx3", "GHSA-6hcq-hmm3-jj3c", "GHSA-6p4f-wcwh-5vvm", "GHSA-72pg-x5f8-j25j", "GHSA-957g-f97v-vppc", "GHSA-9f52-rjqv-25qv", "GHSA-cjpg-rgq5-fr37", "GHSA-h3qp-gqrc-q736", "GHSA-j9f9-w8pj-32f8", "GHSA-mq64-j8f9-9gcj", "GHSA-pc63-qcmh-9cmg", "GHSA-q723-847q-5g8g", "GHSA-r5w3-xv2f-j59q", "GHSA-wg35-8jpf-2xv3", "GHSA-wxpp-56q6-5pcg", "GHSA-x23c-287f-qqv5" ], "description": "Your scanner matched the product, not the artifact: cpe vmware:spring_framework puts every Spring Framework advisory on spring-core. None of these 28 is about spring-core. Sixteen are reported on spring-webmvc, spring-websocket or spring-expression too and are answered there. CVE-2026-47890 starts at 6.2.0, above the 6.1.15 of 24.4. Eleven are about Spring WebFlux, JMS, RSocket and the FreeMarker template loader, whose jars a Vaadin 24.4 application does not resolve. Eight others reported here are about jars you do have and are answered as their own verdicts.", "affects": ">=24.4,<24.5", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.springframework/spring-core", "cves": [ "CVE-2026-22735", "CVE-2026-22737", "CVE-2026-22740", "CVE-2026-22741", "CVE-2026-22745", "CVE-2026-41838", "CVE-2026-41839", "CVE-2026-41840", "CVE-2026-41841", "CVE-2026-41842", "CVE-2026-41843", "CVE-2026-41844", "CVE-2026-41845", "CVE-2026-41846", "CVE-2026-41850", "CVE-2026-41851", "CVE-2026-41852", "CVE-2026-41853", "CVE-2026-41854", "CVE-2026-41855", "CVE-2026-47884", "CVE-2026-47885", "CVE-2026-47888", "CVE-2026-47889", "CVE-2026-47890", "CVE-2026-47891", "CVE-2026-47892", "CVE-2026-47893", "CVE-2026-59280" ], "aliases": [ "GHSA-3chg-m5w7-qfv5", "GHSA-4773-3jfm-qmx3", "GHSA-6hcq-hmm3-jj3c", "GHSA-6p4f-wcwh-5vvm", "GHSA-72pg-x5f8-j25j", "GHSA-7m2p-62gw-p8qq", "GHSA-957g-f97v-vppc", "GHSA-9f52-rjqv-25qv", "GHSA-cjpg-rgq5-fr37", "GHSA-h3qp-gqrc-q736", "GHSA-j9f9-w8pj-32f8", "GHSA-mq64-j8f9-9gcj", "GHSA-pc63-qcmh-9cmg", "GHSA-q723-847q-5g8g", "GHSA-r5w3-xv2f-j59q", "GHSA-wg35-8jpf-2xv3", "GHSA-wxpp-56q6-5pcg", "GHSA-x23c-287f-qqv5" ], "description": "Your scanner matched the product, not the artifact: cpe vmware:spring_framework puts every Spring Framework advisory on spring-core. None of these 29 is about spring-core. Eighteen are reported on spring-webmvc, spring-web, spring-websocket or spring-expression too and are answered there. Eleven are about Spring WebFlux, JMS, RSocket and the FreeMarker template loader, whose jars a Vaadin 24.7 application does not resolve, with or without Control Center. Eight others reported here are about jars you do have and are answered as their own verdicts.", "affects": ">=24.7,<24.8", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.springframework/spring-core", "cves": [ "CVE-2026-47884", "CVE-2026-47885", "CVE-2026-47888", "CVE-2026-47889", "CVE-2026-47890", "CVE-2026-47891", "CVE-2026-47892", "CVE-2026-47893", "CVE-2026-59280" ], "aliases": [ "GHSA-j9f9-w8pj-32f8", "GHSA-pc63-qcmh-9cmg" ], "description": "Your scanner matched the product, not the artifact: cpe vmware:spring_framework puts every Spring Framework advisory on spring-core. None of these nine is about spring-core. CVE-2026-47884 and CVE-2026-47890 are about spring-webmvc and are answered on that coordinate. The other seven are about Spring WebFlux, RSocket and the FreeMarker template loader, and spring-webflux, spring-messaging and spring-context-support are not resolved by a Vaadin 24.9 or 24.10 application.", "affects": ">=24.9,<25", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:maven/org.springframework/spring-core", "cves": [ "CVE-2025-41249" ], "aliases": [ "GHSA-jmp9-x22r-554x" ], "description": "The advisory states its own conditions and a Vaadin application meets none of them by itself. Spring's annotation lookup can miss an annotation on a method inherited from a generic superclass or interface with unbounded type parameters, and that only matters when the annotation is the thing deciding access. In its own words you are not affected if you do not use Spring Security's @EnableMethodSecurity, or if you do not put security annotations on methods in generic superclasses or generic interfaces. Vaadin does neither. If your own services are annotated that way, and they are reached through a generic interface, read it on your code, because there it is an authorization bypass.", "affects": "<24", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework/spring-core", "cves": [ "CVE-2025-41249" ], "aliases": [ "GHSA-jmp9-x22r-554x" ], "description": "The advisory states its own conditions and a Vaadin application meets none of them by itself. Spring's annotation lookup can miss an annotation on a method inherited from a generic superclass or interface, which matters when that annotation decides access. In its own words you are not affected if you do not use Spring Security's @EnableMethodSecurity, or do not put security annotations on methods in generic superclasses or interfaces. Nothing on a Vaadin 24 classpath uses @EnableMethodSecurity. If your own services do, read it on your code.", "affects": ">=24.9,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework/spring-core", "cves": [ "CVE-2025-41249" ], "aliases": [ "GHSA-jmp9-x22r-554x" ], "description": "The advisory states its own conditions and a Vaadin application meets none of them by itself. Spring's annotation lookup can miss an annotation on a method inherited from a generic superclass or interface, which matters when that annotation decides access. In its own words you are not affected if you do not use Spring Security's @EnableMethodSecurity, or do not put security annotations on methods in generic superclasses or interfaces. Nothing on a Vaadin 24 classpath uses @EnableMethodSecurity. If your own services do, read it on your code.", "affects": ">=24.4,<24.9", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework/spring-webmvc", "cves": [ "CVE-2026-47884", "CVE-2026-47890" ], "aliases": [ "GHSA-j9f9-w8pj-32f8", "GHSA-pc63-qcmh-9cmg" ], "description": "Two critical Spring MVC advisories about features a Vaadin application does not use. CVE-2026-47884 needs your application to render through XsltView under a /** mapping that renders a view without naming it, which turns into server side request forgery and then remote code execution. CVE-2026-47890 needs Server Sent Events returning view fragments, and starts at 6.2.0. Nothing on a Vaadin classpath refers to XsltView, SseEmitter or FragmentsRendering except spring-webmvc itself, and Vaadin pushes through Atmosphere. If you have MVC controllers of either shape, read these on your own code, where they are critical.", "affects": ">=24.9,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework/spring-webmvc", "cves": [ "CVE-2026-47884", "CVE-2026-47890" ], "aliases": [ "GHSA-j9f9-w8pj-32f8", "GHSA-pc63-qcmh-9cmg" ], "description": "Two critical Spring MVC advisories about features a Vaadin application does not use. CVE-2026-47884 needs your application to render through XsltView under a /** mapping that renders a view without naming it, which turns into server side request forgery and then remote code execution. CVE-2026-47890 needs Server Sent Events returning view fragments, and starts at 6.2.0. Nothing on a Vaadin classpath refers to XsltView, SseEmitter or FragmentsRendering except spring-webmvc itself, and Vaadin pushes through Atmosphere. If you have MVC controllers of either shape, read these on your own code, where they are critical.", "affects": ">=24.4,<24.9", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework/spring-webmvc", "cves": [ "CVE-2026-47884" ], "aliases": [ "GHSA-pc63-qcmh-9cmg" ], "description": "Spring MVC advisories about features a Vaadin application does not use. CVE-2026-47884 needs your application to render through XsltView and to have a /** mapping that renders a view without naming it, and that combination is what turns it into a server side request forgery and then remote code execution. Neither class is touched by anything on a Vaadin classpath: XsltView and SseEmitter are referenced only by spring-webmvc itself, and Vaadin's own push goes through Atmosphere rather than Spring's SSE. If you have written MVC controllers of either shape alongside your Vaadin views, read these on your own code, because there they are real and they are critical.", "affects": "<24", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:maven/org.springframework/spring-websocket", "cves": [ "CVE-2025-41254", "CVE-2026-41838" ], "aliases": [ "GHSA-7fch-4f2f-jcgm", "GHSA-q723-847q-5g8g" ], "description": "Both need you to have built a Spring WebSocket application, and Vaadin's push is not one. CVE-2025-41254 lets an attacker send unauthorized messages through STOMP over WebSocket, which needs a STOMP broker and the message security rules that go with it. CVE-2026-41838 is that the session ids spring-websocket generates are not cryptographically unpredictable, which matters when authorization leans on them. Vaadin pushes through Atmosphere: the only thing it takes from spring-websocket is registering the endpoint, and nothing in Vaadin handles a STOMP frame or reads a spring-websocket session id. If you have your own STOMP endpoints beside your Vaadin views, read both on that code.", "affects": "<24", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:npm/@apidevtools/json-schema-ref-parser", "cves": [ "CVE-2026-15195" ], "aliases": [], "description": "The flaw is in the version you have, although the advisory lists only 15.3.0 to 15.3.5: Pointer.set in 11.7.2 walks a $ref path with no check for __proto__, which is the check 15.3.6 adds, so a crafted path can write onto Object.prototype. It does not reach a deployed application. 11.7.2 arrives only through @apidevtools/swagger-parser 10.1.1 under the Hilla code generator, which Vaadin declares as a development dependency, and the generator reads the OpenAPI document built from your own endpoint classes during the build.", "affects": ">=25.2", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/@opentelemetry/core", "cves": [ "CVE-2026-54285" ], "aliases": [ "GHSA-8988-4f7v-96qf" ], "description": "The package is there and the vulnerable code is not reached. The advisory is about W3CBaggagePropagator.extract, which parses baggage headers arriving from somewhere else. A Vaadin application uses the browser SDK to start its own spans and never extracts inbound baggage, so that function is not on any execution path.", "affects": "*", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/body-parser", "cves": [ "CVE-2026-111181" ], "aliases": [ "GHSA-27r3-jxmh-p828" ], "description": "body-parser is here because the webpack development server runs on Express, and that server is in nothing you deploy. The advisory is a crash: a request with a compressed body followed by trailing bytes ends the Node process that parses it. The only server in this tree is the one a developer starts while working: Vaadin writes webpack-dev-server into the devDependencies of the generated package.json, and a production build produces the bundle rather than the server.", "affects": "<23", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/braces", "cves": [ "CVE-2026-93687" ], "aliases": [], "description": "braces expands brace patterns such as {a,b}, and a deeply nested one exhausts the stack and ends the Node process. On Vaadin 14 and 23 it arrives only through frontend build tooling that Vaadin declares as development dependencies: chokidar and micromatch under the webpack toolchain on 14, and under vite-plugin-checker on 23. The patterns it expands are globs from that tooling's configuration, not anything a request carries, and it is in nothing the browser loads.", "affects": "<24", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/deepmerge", "cves": [ "CVE-2026-93753", "GHSA-gcqx-w48m-w2h4" ], "aliases": [], "description": "deepmerge reaches Vaadin 23.6, 24.4 and 24.7 only inside workbox-build, the tool that generates the service worker while your frontend is built, which Vaadin declares as a development dependency. It is in nothing the browser loads and in nothing you deploy. The advisory is about objects an attacker supplies to a merge, and the one package that calls deepmerge there, @rollup/plugin-node-resolve, calls it once when it loads, to copy its own built in defaults. Nothing you or a request provide is merged.", "affects": ">=23,<24.9", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/dompurify", "cves": [ "CVE-2025-15599", "CVE-2025-26791", "CVE-2026-0540", "CVE-2026-109345", "CVE-2026-116802", "CVE-2026-116803", "CVE-2026-41239", "CVE-2026-41240", "CVE-2026-49458", "CVE-2026-49459", "CVE-2026-49978", "CVE-2026-65898", "CVE-2026-65899", "CVE-2026-65901", "CVE-2026-65902", "CVE-2026-65903", "CVE-2026-65912", "CVE-2026-65913", "CVE-2026-65914", "CVE-2026-66010", "CVE-2026-75838", "GHSA-c6gr-qvv4-5v3f", "GHSA-mrv2-3pqr-j5jr" ], "aliases": [ "GHSA-39q2-94rc-95cp", "GHSA-55q2-fjhq-7xh7", "GHSA-6688-9rhm-gjv2", "GHSA-76mc-f452-cxcm", "GHSA-c2j3-45gr-mqc4", "GHSA-cj63-jhhr-wcxv", "GHSA-cjmm-f4jc-qw8r", "GHSA-cmwh-pvxp-8882", "GHSA-crv5-9vww-q3g8", "GHSA-h7mw-gpvr-xq4m", "GHSA-h8r8-wccr-v5f2", "GHSA-hpcv-96wg-7vj8", "GHSA-r47g-fvhr-h676", "GHSA-rp9w-3fw7-7cwq", "GHSA-v2wj-7wpq-c8vv", "GHSA-v8jm-5vwx-cfxm", "GHSA-vhxf-7vqr-mrjg", "GHSA-vxr8-fq34-vvx9", "GHSA-x4vx-rjvf-j5p4" ], "description": "DOMPurify reaches a Vaadin 14 application only through @vaadin/vaadin-charts 6.3.8, which pins 2.5.7 exactly and uses it to strip markup from every string in the chart options. The production build puts both in the fallback chunk, which the browser fetches only when a view uses a component outside the eager bundle. Charts calls sanitize with no options, so advisories that need SAFE_FOR_TEMPLATES, IN_PLACE, PARSER_MEDIA_TYPE or a hook are never met by Vaadin's call. The rest are sanitiser bypasses: they matter only if a Chart of yours shows text somebody else wrote.", "affects": "<23", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:npm/dompurify", "cves": [ "CVE-2026-109345", "CVE-2026-75838", "GHSA-6688-9rhm-gjv2" ], "aliases": [ "GHSA-55q2-fjhq-7xh7" ], "description": "Both advisories are about IN_PLACE, the mode where DOMPurify cleans a DOM node you hand it instead of a string, and CVE-2026-75838 also needs a hook of your own that removes nodes. The only caller of DOMPurify in the frontend Vaadin ships on 25.2, 25.3 and 25.4 is @vaadin/markdown, which passes a string with one option, CUSTOM_ELEMENT_HANDLING, and registers no hook. Nothing Vaadin runs meets either condition. Your own code is the boundary: a call with IN_PLACE is in the position the advisories describe.", "affects": ">=25.2", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:npm/dompurify", "cves": [ "CVE-2026-116802", "CVE-2026-116803", "CVE-2026-116804", "GHSA-c6gr-qvv4-5v3f", "GHSA-cg2g-xh64-v4q7", "GHSA-mrv2-3pqr-j5jr" ], "aliases": [], "description": "DOMPurify reaches a Vaadin 24.9 or 24.10 application through @vaadin/markdown, the only caller in the frontend Vaadin ships, which sanitises a string with one option, CUSTOM_ELEMENT_HANDLING, and registers no hook. These three need options Vaadin never sets: SAFE_FOR_TEMPLATES with a DOM returning mode, IN_PLACE with a hook of your own that removes nodes, or PARSER_MEDIA_TYPE set to application/xhtml+xml. Only your own code can create those conditions.", "affects": ">=24.9,<25", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:npm/esbuild", "cves": [ "GHSA-67mh-4wv8-2f99" ], "aliases": [], "description": "esbuild is part of what builds your frontend and of nothing you deploy, and this advisory is about its development server: any website open in the developer's browser can send it requests and read the answers. The server runs on a developer's machine while they work and is not started by a production build. esbuild is here only because vite depends on it, and the same answer already covers the 24 series.", "affects": ">=23,<24", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/esbuild", "cves": [ "GHSA-67mh-4wv8-2f99" ], "aliases": [], "description": "esbuild is part of what builds your frontend and of nothing you deploy, and this advisory is about its development server. It says so itself: any website open in the developer's browser can send requests to that server and read the answers. That server runs on a developer's machine while they work and is not started by a production build. Same shape as the vite advisories on these lines, and for the same reason: esbuild is here only because vite depends on it.", "affects": ">=24.4,<24.7", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/fast-uri", "cves": [ "CVE-2026-110095", "CVE-2026-110180", "CVE-2026-110306", "CVE-2026-110725" ], "aliases": [ "GHSA-333x-w4r6-6crp", "GHSA-w74x-v6f9-j3xg", "GHSA-wjr9-j795-jxcr", "GHSA-xhq7-xmqj-769h" ], "description": "fast-uri parses URIs for a JSON schema validator that runs while your frontend is built, and it is in nothing you deploy. It arrives under ajv, which the Hilla code generator and the service worker builder use, and the lockfile each release ships marks it as a development dependency. All four advisories are about what it does with a URI it is given: a relative reference that compares equal when it should not, a host it canonicalises differently from the browser, a scheme it reads through percent encoding and a first segment it does not escape. The URIs it sees belong to your own project schema at build time, and the production bundle has no copy of the package to reach.", "affects": ">=24.4", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/fast-uri", "cves": [ "CVE-2026-16221", "CVE-2026-18446", "CVE-2026-75899", "CVE-2026-75931", "CVE-2026-75975", "CVE-2026-76172", "CVE-2026-84292", "CVE-2026-86472" ], "aliases": [ "GHSA-5jgf-p345-68v8", "GHSA-7p8r-x3mc-p8w7", "GHSA-f65p-4m7j-42xc", "GHSA-fph4-wmhf-6fwf", "GHSA-hrr3-gc8f-f4qj", "GHSA-jqff-g426-hqxp", "GHSA-qw65-cvwx-89v3", "GHSA-v2hh-gcrm-f6hx" ], "description": "fast-uri parses URIs for the ajv schema validator, which on 25.2 runs only while your frontend is built: it arrives under the Hilla code generator and the service worker builder, and the lockfile of every 25.2 release marks it as a development dependency. All eight advisories are about how it handles a URI it is given, and the URIs it sees there come from your own project schema at build time. The production bundle has no copy to reach.", "affects": ">=25.2,<25.3", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/glob", "cves": [ "CVE-2026-118773" ], "aliases": [ "GHSA-3g3m-2fjr-6pw4" ], "description": "The defect is that a glob walk keeps reading directories after its AbortSignal has fired, which only matters to a caller that relies on a signal to bound how much work a walk does. Nothing in a Vaadin build passes one. glob runs on the build machine, called by the theme plugins of flow and by workbox-build on the output directory, always through globSync and never with a signal, and it is not in the bundle the browser loads.", "affects": ">=24,<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/highcharts", "cves": [ "CVE-2021-29489", "CVE-2026-118250", "CVE-2026-118251", "GHSA-5793-x2q3-c3q7", "GHSA-gr4j-r575-g665", "GHSA-rmqc-xvr3-v46c" ], "aliases": [ "GHSA-8j65-4pcq-xq95" ], "description": "Highcharts is what Vaadin Charts draws with, so this reaches the browser, and every advisory here needs chart options carrying text from an untrusted source. Vaadin Charts 6.3.8 already applies the mitigation the first advisory recommends: it wraps Highcharts.chart, stockChart and the chart, axis, series and legend update methods and runs DOMPurify over every string in the options. Markup in a title or label is therefore stripped unless it bypasses DOMPurify 2.5.7. A link is not markup, so a javascript: URL placed in a link option is not removed by that: the second advisory, and CVE-2026-118251 for credits.href. Credits.setHref in the Java API checks the scheme against the safeUrlSchemes property, which allows every scheme unless you set it. CVE-2026-118250 writes to Object.prototype through a dotted path in series.keys, which only your code sets, through setKeys on the plot options, and Vaadin Charts never sets it. The Vaadin fix for the 2026 advisories, CVE-2026-107588, starts at Vaadin 23 and does not cover this line.", "affects": "<23", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:npm/highcharts", "cves": [ "CVE-2026-118250", "CVE-2026-118251", "GHSA-5793-x2q3-c3q7", "GHSA-rmqc-xvr3-v46c" ], "aliases": [], "description": "Fixed in Vaadin 23.6.16. Vaadin Charts pins Highcharts 9.2.2 exactly, and of the advisories Highsoft disclosed on 29 September 2026, two of them reach Highcharts 9.2.2: writes to Object.prototype through dotted series.keys paths, and a javascript: URL in credits.href. Vaadin 23.6.16 and later apply Highsoft's recommended workarounds to the bundled Highcharts when it loads and keep the same Highcharts version, so your scanner still reports highcharts 9.2.2 on a fixed release. Vaadin published this as CVE-2026-107588.", "affects": ">=23.6.16,<24", "match": "exact", "applicability": "fixed" }, { "purl": "pkg:npm/highcharts", "cves": [ "CVE-2026-118250", "CVE-2026-118251", "GHSA-5793-x2q3-c3q7", "GHSA-rmqc-xvr3-v46c" ], "aliases": [], "description": "Fixed in Vaadin 24.10.11. Vaadin Charts pins Highcharts 9.2.2 exactly, and of the advisories Highsoft disclosed on 29 September 2026, two of them reach Highcharts 9.2.2: writes to Object.prototype through dotted series.keys paths, and a javascript: URL in credits.href. Vaadin 24.10.11 and later apply Highsoft's recommended workarounds to the bundled Highcharts when it loads and keep the same Highcharts version, so your scanner still reports highcharts 9.2.2 on a fixed release. Vaadin published this as CVE-2026-107588.", "affects": ">=24.10.11,<25", "match": "exact", "applicability": "fixed" }, { "purl": "pkg:npm/highcharts", "cves": [ "CVE-2026-118250", "CVE-2026-118251", "GHSA-5793-x2q3-c3q7", "GHSA-rmqc-xvr3-v46c" ], "aliases": [], "description": "Fixed in Vaadin 24.4.24. Vaadin Charts pins Highcharts 9.2.2 exactly, and of the advisories Highsoft disclosed on 29 September 2026, two of them reach Highcharts 9.2.2: writes to Object.prototype through dotted series.keys paths, and a javascript: URL in credits.href. Vaadin 24.4.24 and later apply Highsoft's recommended workarounds to the bundled Highcharts when it loads and keep the same Highcharts version, so your scanner still reports highcharts 9.2.2 on a fixed release. Vaadin published this as CVE-2026-107588.", "affects": ">=24.4.24,<24.5", "match": "exact", "applicability": "fixed" }, { "purl": "pkg:npm/highcharts", "cves": [ "CVE-2026-118250", "CVE-2026-118251", "GHSA-5793-x2q3-c3q7", "GHSA-rmqc-xvr3-v46c" ], "aliases": [], "description": "Fixed in Vaadin 24.7.16. Vaadin Charts pins Highcharts 9.2.2 exactly, and of the advisories Highsoft disclosed on 29 September 2026, two of them reach Highcharts 9.2.2: writes to Object.prototype through dotted series.keys paths, and a javascript: URL in credits.href. Vaadin 24.7.16 and later apply Highsoft's recommended workarounds to the bundled Highcharts when it loads and keep the same Highcharts version, so your scanner still reports highcharts 9.2.2 on a fixed release. Vaadin published this as CVE-2026-107588.", "affects": ">=24.7.16,<24.8", "match": "exact", "applicability": "fixed" }, { "purl": "pkg:npm/highcharts", "cves": [ "CVE-2026-118250", "CVE-2026-118251", "GHSA-5793-x2q3-c3q7", "GHSA-rmqc-xvr3-v46c" ], "aliases": [], "description": "Fixed in Vaadin 24.9.23. Vaadin Charts pins Highcharts 9.2.2 exactly, and of the advisories Highsoft disclosed on 29 September 2026, two of them reach Highcharts 9.2.2: writes to Object.prototype through dotted series.keys paths, and a javascript: URL in credits.href. Vaadin 24.9.23 and later apply Highsoft's recommended workarounds to the bundled Highcharts when it loads and keep the same Highcharts version, so your scanner still reports highcharts 9.2.2 on a fixed release. Vaadin published this as CVE-2026-107588.", "affects": ">=24.9.23,<24.10", "match": "exact", "applicability": "fixed" }, { "purl": "pkg:npm/highcharts", "cves": [ "CVE-2026-116796", "CVE-2026-118244", "CVE-2026-118246", "CVE-2026-118250", "CVE-2026-118251", "GHSA-35rr-xwfh-x789", "GHSA-5793-x2q3-c3q7", "GHSA-65hg-cf3f-5m39", "GHSA-mw4f-gj5x-6xr4", "GHSA-rmqc-xvr3-v46c" ], "aliases": [], "description": "Fixed in Vaadin 25.2.10. Vaadin Charts pins Highcharts 12.2.0 exactly, and of the advisories Highsoft disclosed on 29 September 2026, all five reach Highcharts 12.2.0: writes to Object.prototype through dotted series.keys paths, and cross site scripting through credits.href, breadcrumbs.style, HTML text parsing while printing, and xlink:href in exported charts. Vaadin 25.2.10 and later apply Highsoft's recommended workarounds to the bundled Highcharts when it loads and keep the same Highcharts version, so your scanner still reports highcharts 12.2.0 on a fixed release. Vaadin published this as CVE-2026-107588.", "affects": ">=25.2.10,<25.3", "match": "exact", "applicability": "fixed" }, { "purl": "pkg:npm/highcharts", "cves": [ "CVE-2026-116796", "CVE-2026-118244", "CVE-2026-118246", "CVE-2026-118250", "CVE-2026-118251", "GHSA-35rr-xwfh-x789", "GHSA-5793-x2q3-c3q7", "GHSA-65hg-cf3f-5m39", "GHSA-mw4f-gj5x-6xr4", "GHSA-rmqc-xvr3-v46c" ], "aliases": [], "description": "Fixed in Vaadin 25.3.1. Vaadin Charts pins Highcharts 12.2.0 exactly, and of the advisories Highsoft disclosed on 29 September 2026, all five reach Highcharts 12.2.0: writes to Object.prototype through dotted series.keys paths, and cross site scripting through credits.href, breadcrumbs.style, HTML text parsing while printing, and xlink:href in exported charts. Vaadin 25.3.1 and later apply Highsoft's recommended workarounds to the bundled Highcharts when it loads and keep the same Highcharts version, so your scanner still reports highcharts 12.2.0 on a fixed release. Vaadin published this as CVE-2026-107588.", "affects": ">=25.3.1,<25.4", "match": "exact", "applicability": "fixed" }, { "purl": "pkg:npm/highcharts", "cves": [ "CVE-2026-116796", "CVE-2026-118244", "CVE-2026-118246", "CVE-2026-118250", "CVE-2026-118251", "GHSA-35rr-xwfh-x789", "GHSA-5793-x2q3-c3q7", "GHSA-65hg-cf3f-5m39", "GHSA-mw4f-gj5x-6xr4", "GHSA-rmqc-xvr3-v46c" ], "aliases": [], "description": "Fixed in Vaadin 25.4.0-alpha3. Vaadin Charts pins Highcharts 12.2.0 exactly, and of the advisories Highsoft disclosed on 29 September 2026, all five reach Highcharts 12.2.0: writes to Object.prototype through dotted series.keys paths, and cross site scripting through credits.href, breadcrumbs.style, HTML text parsing while printing, and xlink:href in exported charts. Vaadin 25.4.0-alpha3 and later apply Highsoft's recommended workarounds to the bundled Highcharts when it loads and keep the same Highcharts version, so your scanner still reports highcharts 12.2.0 on a fixed release. Vaadin published this as CVE-2026-107588.", "affects": ">=25.4.0-alpha3,<25.5", "match": "exact", "applicability": "fixed" }, { "purl": "pkg:npm/libxmljs2", "cves": [ "CVE-2024-34393", "CVE-2024-34394" ], "aliases": [], "description": "The package is not in a Vaadin application. It reaches this report through @cyclonedx/cyclonedx-npm, the tool that writes the SBOM this page is measured from, which runs beside the build and ships with nothing.", "affects": "*", "match": "exact", "applicability": "not_affected" }, { "purl": "pkg:npm/micromatch", "cves": [ "CVE-2024-4067" ], "aliases": [ "GHSA-952p-6rrq-rcjv" ], "description": "micromatch is part of the frontend build on Vaadin 24.4 and not of what the browser loads. 24.4.0 to 24.4.10 resolve 4.0.7, inside the advisory, under fast-glob under vite-plugin-checker, the type checker Vaadin names as a development dependency; 24.4.11 to 24.4.23 resolve 4.0.8, the fix, and 24.4.24 onward carry none. The advisory is a regular expression denial of service through a glob pattern, and the patterns that checker matches come from the build configuration.", "affects": ">=24.4,<24.5", "match": "exact", "applicability": "not_affected" }, { "purl": "pkg:npm/minimatch", "cves": [ "CVE-2026-118764" ], "aliases": [ "GHSA-g3hv-75wg-m249" ], "description": "The code is there: minimatch 9.0.9 and 10.2.6 carry the pattern optimiser the advisory describes, and glob calls it with optimizationLevel 2. What it needs is an attacker who chooses the glob pattern, and in a Vaadin build nobody outside the project does. minimatch runs only on the build machine, under glob and workbox-build, and is not in the bundle the browser loads. The patterns it is handed are fixed by Vaadin, **/* for the service worker and *.css for the theme, or written by the developer in the assets section of their own theme.json. 5.1.9, the other copy on these lines, predates the optimiser.", "affects": ">=24,<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/minimatch", "cves": [ "CVE-2026-118764" ], "aliases": [ "GHSA-g3hv-75wg-m249" ], "description": "The advisory describes firstPhasePreProcess(), the pattern optimiser minimatch gained in its 9.x series and runs when optimizationLevel is 2 or more. The copies that reach these lines are 3.1.5 and 5.1.9, which predate it: neither has that function nor an optimizationLevel option, so there is nothing for the pattern to amplify. The structured range of the advisory says below 11.0.1, which is wider than the code it describes.", "affects": "<24", "match": "exact", "applicability": "false_positive" }, { "purl": "pkg:npm/node-forge", "cves": [ "CVE-2026-118775", "CVE-2026-118777", "CVE-2026-118778", "CVE-2026-118779", "CVE-2026-118780", "CVE-2026-118781", "CVE-2026-118782", "CVE-2026-119186", "CVE-2026-119187", "CVE-2026-119188", "CVE-2026-119190", "CVE-2026-33894" ], "aliases": [ "CVE-2026-85393", "GHSA-4487-j8r4-4g2f", "GHSA-4642-5mcj-2rqw", "GHSA-525v-9gp9-w22h", "GHSA-5cwg-6vw7-rj6p", "GHSA-5x38-2vff-x55p", "GHSA-6wvx-3r32-xmcg", "GHSA-7wch-p9px-956x", "GHSA-86w9-cpqp-85rv", "GHSA-8hrf-8g6f-7xwp", "GHSA-h6cr-wjv9-3cpp", "GHSA-hqq3-7jhf-c5jx", "GHSA-jc66-7q78-782g", "GHSA-ppp5-5v6c-4jwp" ], "description": "node-forge is here only so the development server can make itself a self signed certificate. It arrives under selfsigned, which arrives under webpack-dev-server, which Vaadin writes into devDependencies, and it is not in the bundle the browser loads. The development server Vaadin configures speaks plain http and never loads selfsigned at all. Even where an application switches it to https, selfsigned only generates a fresh key pair and a certificate for localhost and checks that certificate against itself: nothing it does verifies an RSA signature from elsewhere, decodes a PEM it was given, opens a TLS connection, reads PKCS#12, handles cookies or decrypts AES-GCM, which is where these advisories live. node-forge 1.4.1 fixes the eleven published in October 2026, and selfsigned accepts any 1.x, so a build that installs its npm packages again picks it up.", "affects": "<23", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/path-to-regexp", "cves": [ "CVE-2024-45296" ], "aliases": [ "CVE-2026-4867", "GHSA-37ch-88jc-xwx2", "GHSA-9wv6-86v2-598j" ], "description": "This needs a route of a particular shape, and it hangs the visitor's own browser rather than your server. path-to-regexp turns a route pattern into a regular expression, and it produces a backtracking one whenever a single segment holds two parameters separated by anything other than a dot, as in /:a-:b. A path crafted against such a pattern then takes a very long time to match. It reaches a Vaadin application through @vaadin/router, the client side router, so the matching happens in the browser: what stops is the tab of whoever followed the link. Look at your own route patterns for two parameters in one segment.", "affects": ">=23,<24", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:npm/path-to-regexp", "cves": [ "CVE-2024-45296" ], "aliases": [ "CVE-2026-4867", "GHSA-37ch-88jc-xwx2", "GHSA-9wv6-86v2-598j" ], "description": "This needs a route of a particular shape, and it hangs the visitor's own browser rather than your server. path-to-regexp turns a route pattern into a regular expression, and it produces a backtracking one whenever a single segment holds two parameters separated by anything other than a dot, as in /:a-:b. A path crafted against such a pattern then takes a very long time to match. It reaches a Vaadin application through @vaadin/router, the client side router, so the matching happens in the browser: what stops is the tab of whoever followed the link. Look at your own route patterns for two parameters in one segment. If there are none, there is no regular expression of that kind to attack.", "affects": ">=24.4,<24.7", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:npm/railroad-diagrams", "cves": [ "CVE-2024-26467" ], "aliases": [], "description": "The package is not in a Vaadin application. It reaches this report through @cyclonedx/cyclonedx-npm, the tool that writes the SBOM this page is measured from, which runs beside the build and ships with nothing.", "affects": "*", "match": "exact", "applicability": "not_affected" }, { "purl": "pkg:npm/react-router", "cves": [ "CVE-2026-53669" ], "aliases": [ "GHSA-wrjc-x8rr-h8h6" ], "description": "A path beginning with a backslash can be read by the browser as an address on another site, and React Router 6 passes it through. Every way Vaadin itself hands a path to the router is guarded before the router sees it: a click on a link is dropped unless the anchor's origin equals the window's, and then again unless its href starts with the document's base URI, and both checks are done by the browser's own URL parser, which resolves a backslash the same way the address bar would. The one path that is not guarded is the one your server chooses, because there Vaadin navigates where the application told it to. So the question is your own code: if you call UI.navigate, or set a location, with a value that came from a query parameter, a form field or a database row an attacker can write, then that value can take the browser off your site. Validate it before you navigate, the way you would validate any redirect target.", "affects": ">=24.4,<24.7", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:npm/react-router", "cves": [ "CVE-2026-53666" ], "aliases": [ "GHSA-337j-9hxr-rhxg" ], "description": "This one is about server side rendering, which a Vaadin application does not do. The advisory says so in its own words: it does not affect Declarative Mode and only impacts Framework Mode and Data Mode applications doing manual SSR and hydration. Flow's React integration renders in the browser and nothing else: its frontend sources contain no hydrateRoot, no StaticRouter, no createStaticHandler and no reference to deserializeErrors, which is the function the advisory is about. You would have to write your own server rendering around React Router, outside anything Vaadin generates, and then let attacker input shape the errors it serialises.", "affects": ">=24.4,<24.7", "match": "exact", "applicability": "configuration" }, { "purl": "pkg:npm/serialize-javascript", "cves": [ "CVE-2020-7660", "CVE-2026-34043" ], "aliases": [ "GHSA-5c6j-r48x-rmvq", "GHSA-qj8w-gfj5-8c6v" ], "description": "serialize-javascript runs while your frontend is built and is in nothing you deploy. On 14 it arrives under compression-webpack-plugin and copy-webpack-plugin, on 23 under rollup-plugin-terser inside workbox-build, the service worker builder, and Vaadin declares those as development dependencies. CVE-2026-34043 is CPU exhaustion on a crafted array like object and needs an attacker to shape what the build serialises, which is the build's own data. CVE-2020-7660 does not apply: it is fixed in 3.1.0, and 14 resolves 6.0.2 and 23 resolves 4.0.0.", "affects": "<24", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/serialize-javascript", "cves": [ "CVE-2026-115754", "CVE-2026-115897" ], "aliases": [ "GHSA-m5mm-p8h7-m29v" ], "description": "serialize-javascript turns build time data into JavaScript source while your frontend is built, and it is in nothing you deploy. Both advisories are cross site scripting through a closing script tag left unescaped, which matters when the serialised value comes from somebody else and lands in a page. On 14 it arrives under compression-webpack-plugin and copy-webpack-plugin, on 23 under rollup-plugin-terser inside workbox-build; Vaadin declares those as development dependencies, so what it serialises is build output.", "affects": "<24", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/serialize-javascript", "cves": [ "CVE-2026-115754", "CVE-2026-115897" ], "aliases": [ "GHSA-m5mm-p8h7-m29v" ], "description": "serialize-javascript turns build time data into JavaScript source while your frontend is built, and it is in nothing you deploy. Both advisories are cross site scripting through a closing script tag that is not escaped, which matters when the serialised value comes from somebody else and lands in a page. Here the value is build output: the webpack plugins that compress and copy assets, and the terser plugin under the service worker builder, call it on data the build itself produced. The lockfile each release ships marks the package as a development dependency.", "affects": ">=24", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/uuid", "cves": [ "CVE-2026-41907" ], "aliases": [ "CVE-2026-41988", "GHSA-w5hq-g745-h8pq" ], "description": "A missing bounds check when a caller passes its own buffer to the v3, v5 or v6 generators. It reaches a Vaadin 14 build under sockjs, the WebSocket fallback of the development server, and not through anything the browser loads. Nothing in a Vaadin application calls those generators at all, let alone with a buffer of its own.", "affects": "<23", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/vite", "cves": [ "CVE-2024-52011", "CVE-2025-24010", "CVE-2025-30208", "CVE-2025-31125", "CVE-2025-31486", "CVE-2025-32395", "CVE-2025-46565", "CVE-2025-58751", "CVE-2025-58752", "CVE-2025-62522", "CVE-2026-39365", "CVE-2026-53571", "CVE-2026-53632" ], "aliases": [ "GHSA-356w-63v5-8wf4", "GHSA-4r4m-qw57-chr8", "GHSA-4w7w-66w2-5vf9", "GHSA-859w-5945-r5v3", "GHSA-93m4-6634-74q7", "GHSA-c27g-q93r-2cwf", "GHSA-fx2h-pf6j-xcff", "GHSA-g4jq-h2w9-997c", "GHSA-jqfw-vq24-v9c3", "GHSA-v6wh-96g9-6wx3", "GHSA-vg6x-rcgg-rjx6", "GHSA-x574-m823-4x7w", "GHSA-xcj6-pq6g-qj4x" ], "description": "Vite builds your frontend and is not part of it: Vaadin names it as a development dependency, and the archive you deploy carries the bundle it produced, not vite. All thirteen are about its development server: ten let it serve files outside its server.fs rules, two are in the editor launcher it offers, a command injection and an NTLMv2 hash leak, both on Windows, and one lets any website the developer visits send it requests and read the answers. They matter on a developer machine while that server runs.", "affects": "<25", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/vite", "cves": [ "CVE-2026-112942", "CVE-2026-112943", "CVE-2026-112944", "CVE-2026-112945", "CVE-2026-112946" ], "aliases": [ "GHSA-587h-7wmj-h5pm", "GHSA-698v-4r3x-3vcv", "GHSA-9jrq-w75r-8gcw", "GHSA-r825-w8mm-5pxw", "GHSA-rq7h-c2jc-7f22" ], "description": "Nothing you deploy runs vite: Vaadin names it as a development dependency, a production build runs it once to make the bundle, and the archive carries the bundle. All five are about the development server. Three are in launch-editor, which that server uses to open a file in your editor from the error overlay; one is script execution through custom middleware, and one serves files outside server.fs.allow on a server exposed to the network. Each needs that server running plus the condition its advisory states.", "affects": ">=23", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/webpack", "cves": [ "CVE-2025-68157", "CVE-2025-68458" ], "aliases": [ "GHSA-38r7-794h-5758", "GHSA-8fgc-7cc6-rx7x" ], "description": "webpack is what bundles your frontend and is in nothing you deploy, and both advisories are about a webpack feature that a Vaadin build does not use. They are ways around the allowedUris list of buildHttp, the option that lets a build fetch modules over HTTP, one through a redirect and one through userinfo in the URL. A Vaadin build resolves its modules from the npm registry and the project, not over buildHttp, and the result either way is a request made by the build machine.", "affects": "<23", "match": "exact", "applicability": "no_risk" }, { "purl": "pkg:npm/webpack-dev-server", "cves": [ "CVE-2026-14620", "CVE-2026-14631", "CVE-2026-6402", "CVE-2026-9595" ], "aliases": [ "GHSA-79cf-xcqc-c78w", "GHSA-f5vj-f2hx-8m93", "GHSA-m28w-2pqf-7qgj", "GHSA-mx8g-39q3-5c79" ], "description": "This is the development server, and all four advisories are about it serving a developer. One lets another website in the developer's browser forge requests to its internal endpoints, one lets any origin read source over a non HTTPS connection, one intercepts the hot reload WebSocket through a permissive proxy, and one kills it with a malformed Host header. None of that exists in a deployed application: the server is started by the development build and the thing a production build produces is the bundle. Vaadin writes webpack-dev-server into the devDependencies of the generated package.json itself.", "affects": "<23", "match": "exact", "applicability": "no_risk" } ], "skipped": [ { "id": "maven-ch-qos-logback-logback-core-1-2-x", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-ch-qos-logback-logback-core-24-4", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-ch-qos-logback-logback-core-24-7", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-fasterxml-jackson-core-jackson-core-14-23", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-fasterxml-jackson-core-jackson-core-2026", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-fasterxml-jackson-core-jackson-core-24-4-24-7-2026-10-22", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-fasterxml-jackson-core-jackson-core-24-9-number-token", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-fasterxml-jackson-core-jackson-core-24-number-token", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-fasterxml-jackson-core-jackson-core-25", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-fasterxml-jackson-core-jackson-databind-14-23", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-fasterxml-jackson-core-jackson-databind-2026", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-fasterxml-jackson-core-jackson-databind-24-4-24-7-2026-10-22", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-fasterxml-jackson-core-jackson-databind-25", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-vaadin-flow-maven-plugin-2026-7860", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-vaadin-flow-server-2026-2742-14-14-0", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-vaadin-vaadin-2025-9467-stale-range-24-7", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-com-vaadin-vaadin-upload-flow-2025-9467-stale-range-24-7", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-commons-fileupload-commons-fileupload-part-headers-fix-on-the-way", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-io-opentelemetry-opentelemetry-api-baggage-2026-11-03", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-io-opentelemetry-opentelemetry-api-tracestate-24-2026-11-03", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-io-opentelemetry-opentelemetry-api-tracestate-25-2-2026-11-03", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-me-friwi-jcef-api-cef-104", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-net-minidev-json-smart-24-4", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-commons-commons-fileupload2-core-part-headers-fix-on-the-way", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-poi-poi-ooxml-duplicate-zip-entries-23", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-poi-poi-ooxml-duplicate-zip-entries", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-tomcat-embed-tomcat-embed-core-10-1-x-24-4-24-7", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-tomcat-embed-tomcat-embed-core-10-1-x", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-tomcat-embed-tomcat-embed-core-2026-11-03", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-tomcat-embed-tomcat-embed-core-2026-24-4-24-7", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-tomcat-embed-tomcat-embed-core-2026-24-9-24-10", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-tomcat-embed-tomcat-embed-core-2026-9-0", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-tomcat-embed-tomcat-embed-core-24-4-filed-elsewhere", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-tomcat-embed-tomcat-embed-core-24-4", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-tomcat-embed-tomcat-embed-core-24-7", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-tomcat-embed-tomcat-embed-core-9-0-x-rest", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-tomcat-embed-tomcat-embed-core-9-0-x", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-apache-tomcat-embed-tomcat-embed-websocket-2024-23672", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-bouncycastle-bcprov-jdk18on-24-7-2026-10-22", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-retry-spring-retry-24-7", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-security-spring-security-core-24-7", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-security-spring-security-crypto-24-4", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-security-spring-security-web-24-4", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-security-spring-security-web-24-7", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-context-24-4-2026-10-22", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-context-5-3-x", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-core-24", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-core-5-3-x-also-on-24", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-core-5-3-x", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-expression-24-4-2026-10-22", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-expression-24-7", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-expression-5-3-x", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-web-24-4", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-web-24-7", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-web-5-3-x", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-webmvc-24-4-2026-10-22", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-webmvc-24-4", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-webmvc-24-7", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-webmvc-5-3-x", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-websocket-24-4-2026-10-22", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-websocket-24-4", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-springframework-spring-websocket-24-7", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-org-yaml-snakeyaml-1-30", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-tools-jackson-core-jackson-core-2026-10-24", "reason": "applicability is risk, which does not silence a finding" }, { "id": "maven-tools-jackson-core-jackson-databind-2026-10-24", "reason": "applicability is risk, which does not silence a finding" }, { "id": "npm-baseline-browser-mapping", "reason": "applicability is risk, which does not silence a finding" }, { "id": "npm-browserslist", "reason": "applicability is risk, which does not silence a finding" }, { "id": "npm-postcss", "reason": "applicability is risk, which does not silence a finding" }, { "id": "npm-quill-2025-15056-25-4", "reason": "applicability is risk, which does not silence a finding" }, { "id": "npm-quill-2025-15056-before-25-2-13", "reason": "applicability is risk, which does not silence a finding" }, { "id": "npm-quill-2025-15056-before-25-3-5", "reason": "applicability is risk, which does not silence a finding" }, { "id": "npm-react-router", "reason": "applicability is risk, which does not silence a finding" }, { "id": "npm-source-map-js", "reason": "applicability is risk, which does not silence a finding" } ], "uncovered": [] }