fixes #13 add security documents

Author: stevehu

src/SUMMARY.md

@@ -180,3 +180,8 @@
   - [GitHub](./support/github.md) 
     - [Light Bot](./support/github/light-bot.md)
     - [Internal Tools](./support/github/internal-tools.md)
+- [Security](./security.md)
+  - [Known Vulnerabilities](./security/known-vulnerabilities.md)
+    - [CVE-2026-28367](./security/known-vulnerabilities/CVE-2026-28367.md)
+    - [CVE-2026-28368](./security/known-vulnerabilities/CVE-2026-28368.md)
+    - [CVE-2026-28369](./security/known-vulnerabilities/CVE-2026-28369.md)

src/security.md

@@ -0,0 +1,7 @@
+# Security
+
+NetworkNT publishes general security information at [networknt.com/security.html](https://www.networknt.com/security.html).
+
+This section contains security notes that need more project-specific context than a generic vulnerability scanner result can provide. The goal is to explain whether a reported issue is applicable to NetworkNT components, what deployment conditions are required for exploitation, and what technical controls can mitigate the issue.
+
+- [Known Vulnerabilities](./security/known-vulnerabilities.md)

src/security/known-vulnerabilities.md

@@ -0,0 +1,43 @@
+# Known Vulnerabilities
+
+This page tracks known vulnerability reports that can appear in dependency scans and require NetworkNT-specific applicability analysis.
+
+## Undertow Request Smuggling CVEs
+
+The following CVEs are all Undertow HTTP request smuggling issues in the HTTP/1.1 request parsing layer. They are relevant to `light-4j` because `light-4j` uses `io.undertow:undertow-core` as its embedded HTTP server. As of June 10, 2026, `light-4j` manages `undertow-core` at `2.4.1.Final`, and Maven Central still lists `2.4.1.Final` as the latest release.
+
+| CVE | Vulnerability pattern | NetworkNT assessment |
+| --- | --- | --- |
+| [CVE-2026-28367](./known-vulnerabilities/CVE-2026-28367.md) | Non-standard header block terminator forwarded by certain proxies | Conditionally applicable; mitigated by strict edge proxy validation or by not placing Undertow behind an affected HTTP/1.1 proxy path. |
+| [CVE-2026-28368](./known-vulnerabilities/CVE-2026-28368.md) | Header names interpreted differently by an upstream proxy and Undertow | Conditionally applicable; requires a proxy/backend parser mismatch. |
+| [CVE-2026-28369](./known-vulnerabilities/CVE-2026-28369.md) | First header line with leading spaces interpreted differently | Conditionally applicable; requires malformed HTTP/1.1 traffic to reach Undertow through a permissive upstream proxy. |
+
+## General Applicability to light-4j
+
+These issues should not be treated as directly exploitable in every `light-4j` deployment only because `undertow-core` appears in the dependency tree. Request smuggling requires at least two HTTP processors that disagree on where a request starts, ends, or which headers are present. A normal `light-4j` service that terminates client traffic itself does not have a front-end/back-end parser disagreement in the same request path.
+
+The risk becomes relevant when a `light-4j` service is deployed as an Undertow origin behind an upstream HTTP/1.1 proxy, load balancer, gateway, or WAF that accepts malformed requests and forwards them to Undertow in a form Undertow interprets differently. The same inbound condition applies when a `light-4j` router or proxy service is placed behind another upstream proxy. The `light-4j` proxy modules operate on Undertow's parsed `HeaderMap` and create a new outbound Undertow client request; they do not intentionally forward the original raw HTTP header block.
+
+## Standard Mitigations
+
+Use the following controls for customer environments where scanner findings identify these CVEs:
+
+- Prefer the default `light-4j` posture: `enableHttps: true`, `enableHttp: false`, `enableHttp2: true`, and `allowUnescapedCharactersInUrl: false`.
+- Do not expose a `light-4j` HTTP/1.1 listener directly to untrusted networks unless there is a strict edge control in front of it.
+- Configure upstream proxies, load balancers, gateways, and WAFs to reject malformed HTTP/1.1 requests instead of forwarding or normalizing ambiguous header syntax.
+- Avoid older proxy products or legacy load balancer modes known to forward malformed HTTP/1.1 traffic to Undertow. For CVE-2026-28367, Red Hat specifically calls out older Apache Traffic Server and Google Cloud Classic Application Load Balancer configurations as examples.
+- Prefer TLS and HTTP/2 between the client-facing edge and `light-4j` where possible. If the edge terminates HTTP/2 and forwards HTTP/1.1 to `light-4j`, the edge-to-origin HTTP/1.1 hop must still enforce strict request validation.
+- Keep `light-4j` and deployment images current. At the time of this review, Maven Central did not provide a newer `undertow-core` release than `2.4.1.Final`, so deployment controls are still required.
+
+## Red Hat Status Context
+
+Red Hat rates all three CVEs as Important with CNA CVSS 3.1 score 8.7 and high attack complexity. NVD lists a separate 9.1 Critical score, but the Red Hat CNA scoring is more specific to the proxy-dependent request smuggling condition.
+
+Red Hat's product status is not uniform across all products. Red Hat Security Data marks some `undertow-core` product streams, including Red Hat Data Grid 8, Red Hat Fuse 7, and Red Hat JBoss Enterprise Application Platform 7, as `Will not fix`, while other product streams are marked `Affected` or `Not affected`. That status supports treating these as deployment-specific findings rather than assuming every scanner match requires an immediate library replacement.
+
+## References
+
+- [Maven Central undertow-core metadata](https://repo1.maven.org/maven2/io/undertow/undertow-core/maven-metadata.xml)
+- [Red Hat Security Data JSON: CVE-2026-28367](https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-28367.json)
+- [Red Hat Security Data JSON: CVE-2026-28368](https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-28368.json)
+- [Red Hat Security Data JSON: CVE-2026-28369](https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-28369.json)

src/security/known-vulnerabilities/CVE-2026-28367.md

@@ -0,0 +1,44 @@
+# CVE-2026-28367
+
+## Summary
+
+CVE-2026-28367 is an Undertow request smuggling vulnerability involving a non-standard HTTP header block terminator. Red Hat describes the condition as a remote attacker sending a malformed header terminator that can be interpreted differently by certain upstream proxies and Undertow.
+
+Red Hat rates the issue as Important with CVSS 3.1 score 8.7, using high attack complexity because exploitation depends on a compatible proxy/backend parsing mismatch. NVD also lists a 9.1 Critical score, but the Red Hat CNA score better reflects the deployment prerequisite.
+
+## light-4j Applicability
+
+`light-4j` uses Undertow through `io.undertow:undertow-core`, so dependency scanners can report this CVE for `light-4j` applications.
+
+The issue is not directly exploitable in every `light-4j` deployment. It requires an HTTP/1.1 request path where an upstream proxy accepts and forwards a malformed header block terminator, and Undertow interprets the forwarded bytes differently. Red Hat specifically names older Apache Traffic Server versions and Google Cloud Classic Application Load Balancer configurations as examples of proxy environments where this class of issue can matter.
+
+The finding is not applicable, or is not exploitable, when:
+
+- The `light-4j` service is not behind an affected HTTP/1.1 proxy or load balancer.
+- The client-facing edge rejects malformed HTTP/1.1 requests before they reach Undertow.
+- The deployment uses HTTPS and HTTP/2 end to end, without translating malformed HTTP/1.1 traffic into the Undertow origin hop.
+- The `light-4j` service is reachable only through trusted internal traffic controls that enforce strict HTTP request validation.
+
+## Mitigation
+
+For exposed services, configure the upstream proxy, load balancer, gateway, or WAF to reject non-standard HTTP header block terminators before forwarding to `light-4j`. This matches Red Hat's stated mitigation for this CVE.
+
+For `light-4j` configuration, keep the default production posture:
+
+- `enableHttps: true`
+- `enableHttp: false`
+- `enableHttp2: true`
+- `allowUnescapedCharactersInUrl: false`
+
+If a customer must run `light-4j` behind an HTTP/1.1 proxy, validate the exact proxy product and mode. The proxy must reject malformed request framing, not normalize and forward it.
+
+## Customer Response
+
+This CVE is a deployment-dependent Undertow request smuggling issue. NetworkNT has confirmed that `light-4j` embeds Undertow, but exploitability requires a vulnerable upstream HTTP/1.1 proxy path that forwards malformed header termination to Undertow. In recommended `light-4j` deployments, HTTPS/HTTP2 is enabled, clear HTTP is disabled, and edge proxies must enforce strict HTTP request validation. When those controls are in place, the issue is not exploitable in the `light-4j` service.
+
+## References
+
+- [NVD: CVE-2026-28367](https://nvd.nist.gov/vuln/detail/CVE-2026-28367)
+- [Red Hat CVE page: CVE-2026-28367](https://access.redhat.com/security/cve/CVE-2026-28367)
+- [Red Hat Security Data JSON: CVE-2026-28367](https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-28367.json)
+- [CVE Program API: CVE-2026-28367](https://cveawg.mitre.org/api/cve/CVE-2026-28367)

src/security/known-vulnerabilities/CVE-2026-28368.md

@@ -0,0 +1,40 @@
+# CVE-2026-28368
+
+## Summary
+
+CVE-2026-28368 is an Undertow request smuggling vulnerability involving inconsistent HTTP header name parsing. Red Hat describes the condition as specially crafted requests whose header names are interpreted differently by Undertow and an upstream proxy, allowing request smuggling when the two components disagree.
+
+Red Hat rates the issue as Important with CVSS 3.1 score 8.7, using high attack complexity because exploitation depends on an upstream proxy/backend parser mismatch. NVD also lists a 9.1 Critical score, but the Red Hat CNA score better reflects the deployment prerequisite.
+
+## light-4j Applicability
+
+`light-4j` uses Undertow through `io.undertow:undertow-core`, so dependency scanners can report this CVE for `light-4j` applications.
+
+The issue is conditionally applicable only when malformed HTTP/1.1 requests pass through an upstream proxy, load balancer, gateway, or WAF that interprets header names differently from Undertow and forwards the ambiguous request to the `light-4j` origin. A direct client-to-Undertow path does not create the front-end/back-end desynchronization required for request smuggling.
+
+The finding is not applicable, or is not exploitable, when:
+
+- The `light-4j` service is not deployed behind a permissive HTTP/1.1 proxy or load balancer.
+- The upstream proxy rejects malformed or ambiguous header names.
+- The edge-to-origin hop uses strict request validation and does not forward non-compliant header syntax.
+- The deployment uses HTTPS and HTTP/2 end to end, without translating malformed HTTP/1.1 traffic into the Undertow origin hop.
+
+## Mitigation
+
+Red Hat's public mitigation text says a broadly applicable mitigation is not available under its Product Security criteria. For `light-4j` deployments, the practical technical mitigation is still to remove the parser mismatch condition:
+
+- Use a fronting proxy, load balancer, gateway, or WAF that rejects malformed HTTP/1.1 header names.
+- Avoid forwarding raw, ambiguous, or normalized-but-non-compliant HTTP/1.1 requests to Undertow.
+- Prefer the default `light-4j` production posture: HTTPS enabled, clear HTTP disabled, HTTP/2 enabled, and unescaped URL characters disabled.
+- If the deployment requires an HTTP/1.1 hop from edge to `light-4j`, test the exact edge product and configuration for strict header-name validation.
+
+## Customer Response
+
+This CVE is not a standalone application logic issue in `light-4j`; it is a proxy/backend HTTP parsing ambiguity in Undertow. A scanner can flag the Undertow dependency, but exploitability requires a permissive upstream HTTP/1.1 proxy path that forwards ambiguous header names to Undertow. In deployments where the edge rejects malformed headers or uses strict HTTPS/HTTP2 request handling to the service, the issue is not exploitable in `light-4j`.
+
+## References
+
+- [NVD: CVE-2026-28368](https://nvd.nist.gov/vuln/detail/CVE-2026-28368)
+- [Red Hat CVE page: CVE-2026-28368](https://access.redhat.com/security/cve/CVE-2026-28368)
+- [Red Hat Security Data JSON: CVE-2026-28368](https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-28368.json)
+- [CVE Program API: CVE-2026-28368](https://cveawg.mitre.org/api/cve/CVE-2026-28368)

src/security/known-vulnerabilities/CVE-2026-28369.md

@@ -0,0 +1,40 @@
+# CVE-2026-28369
+
+## Summary
+
+CVE-2026-28369 is an Undertow request smuggling vulnerability involving malformed HTTP request headers. Red Hat describes the condition as an HTTP request where the first header line starts with one or more spaces. Undertow strips the leading spaces, which can cause it to interpret the request differently from an upstream proxy.
+
+Red Hat rates the issue as Important with CVSS 3.1 score 8.7, using high attack complexity because exploitation depends on an upstream proxy/backend parser mismatch. NVD also lists a 9.1 Critical score, but the Red Hat CNA score better reflects the deployment prerequisite.
+
+## light-4j Applicability
+
+`light-4j` uses Undertow through `io.undertow:undertow-core`, so dependency scanners can report this CVE for `light-4j` applications.
+
+The issue is conditionally applicable only when a malformed HTTP/1.1 request is accepted by an upstream proxy and forwarded to Undertow in a way that causes the proxy and Undertow to disagree about request boundaries or headers. If the upstream component rejects the malformed header line, the request does not reach Undertow and the smuggling condition is removed.
+
+The finding is not applicable, or is not exploitable, when:
+
+- The `light-4j` service is not behind an upstream HTTP/1.1 proxy that forwards malformed first-header-line syntax.
+- The edge proxy, load balancer, gateway, or WAF rejects header lines with leading whitespace.
+- HTTPS and HTTP/2 are used end to end, without translating malformed HTTP/1.1 traffic into the Undertow origin hop.
+- The `light-4j` listener is protected by network controls and only accepts traffic from trusted components that enforce strict HTTP syntax.
+
+## Mitigation
+
+For `light-4j` deployments, mitigation should focus on strict request validation at the edge and conservative server configuration:
+
+- Configure upstream proxies, load balancers, gateways, and WAFs to reject header lines that begin with whitespace.
+- Do not allow a permissive edge component to normalize and forward malformed HTTP/1.1 requests to Undertow.
+- Prefer the default `light-4j` production posture: HTTPS enabled, clear HTTP disabled, HTTP/2 enabled, and unescaped URL characters disabled.
+- If a customer uses a legacy HTTP/1.1 proxy in front of `light-4j`, verify that it rejects malformed header syntax before forwarding.
+
+## Customer Response
+
+This CVE is a conditional Undertow request smuggling issue. `light-4j` may be flagged because it embeds Undertow, but the issue requires a vulnerable upstream HTTP/1.1 proxy path that forwards malformed header-line syntax to Undertow. With strict edge validation, HTTPS/HTTP2-oriented deployment, and clear HTTP disabled for untrusted access, the issue is not exploitable in `light-4j`.
+
+## References
+
+- [NVD: CVE-2026-28369](https://nvd.nist.gov/vuln/detail/CVE-2026-28369)
+- [Red Hat CVE page: CVE-2026-28369](https://access.redhat.com/security/cve/CVE-2026-28369)
+- [Red Hat Security Data JSON: CVE-2026-28369](https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-28369.json)
+- [CVE Program API: CVE-2026-28369](https://cveawg.mitre.org/api/cve/CVE-2026-28369)