[dependabot]

Bumps follow-redirects from 1.16.0 to 1.16.1 in openam-ui/openam-ui-ria (package-lock.json only), clearing Dependabot alerts #367 and #368. This follows #985, which took the same dependency from 1.15.11 to 1.16.0 for GHSA-r4q5-vmmm-2653; both new advisories are flaws in the cross-origin header stripping that fix extended. openam-ui-ria is the only lock file in the repository that resolves follow-redirects.

Advisories

When a redirect crosses to another host or downgrades HTTPS to HTTP, follow-redirects removes Authorization, Proxy-Authorization, Cookie and any header names the caller lists in the sensitiveHeaders option (added in 1.16.0) before it sends the next request. Both advisories make that removal silently do nothing, so the credentials reach the redirect target.

CVE-2026-111755 / GHSA-8r9p-f939-6h3c (fixed in 1.16.1) — Incorrect regular expression (CWE-185) leading to exposure of sensitive information (CWE-200). The filter is one case-insensitive alternation of the header names, each passed through escapeRegex, which left ^, |, [, { and } unescaped. ^ and | are valid header-name characters, so a declared name such as X-Api^Key or X-Token|Secret never matches and is forwarded, while | also splits the name into unrelated alternatives; a declared name containing [ makes the RegExp constructor throw. The built-in names contain no metacharacters and are not affected. 1.16.1 adds [, ^ and | to the escaped set (follow-redirects@080a76d). The advisory's second, lower-severity point — names pushed into sensitiveHeaders inside beforeRedirect are ignored, because the filter is built once in the constructor — is not changed by 1.16.1.

CVE-2026-111756 / GHSA-q3jh-wrc6-jgq8 (fixed in 1.16.1) — Exposure of sensitive information (CWE-200) through improper removal of sensitive information before transfer (CWE-212). Node's http.request also accepts headers as an alternating [name, value, …] array. removeMatchingHeaders walks the headers with for…in, which yields the indices "0", "1", … for an array, so nothing matches: the built-in credential headers, every sensitiveHeaders entry, the stale Host and, on a POST→GET redirect, the content-* headers are all forwarded. 1.16.1 converts an array to an object in _sanitizeOptions before any stripping (follow-redirects@9865ca4); a name repeated in the array now keeps only its last value.

	Severity	Affected	Fixed in
GHSA-8r9p-f939-6h3c	High — CVSS 4.0 8.2 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N)	>= 1.16.0, < 1.16.1	1.16.1
GHSA-q3jh-wrc6-jgq8	High — CVSS 4.0 8.2 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N)	>= 1.16.0, < 1.16.1	1.16.1

Confidentiality-only: credential disclosure to a redirect target, no code execution.

Impact on OpenAM

None at runtime, none in the build. follow-redirects is a transitive development dependency of openam-ui-ria (dev: true): the single copy in the lock file is pulled in by http-proxy 1.18.1, which karma 6.4.3 requires. No OpenAM source imports it, and it does not end up in the module zip — the assembly packs only target/compiled and the CodeMirror files — or in the WAR.

The Maven build reaches it only through npm run test → grunt karma:build. Karma loads http-proxy, which requires follow-redirects, but Karma creates a proxy only for the entries in config.proxies, and karma.conf.js declares none. Even with a proxy configured, Karma's createProxyServer does not set followRedirects, so http-proxy would send its requests through Node's own http / https; the headers it builds are a plain object copied from the incoming request (common.setupOutgoing), and it never sets sensitiveHeaders. Neither flaw is reachable here. The bump takes the development toolchain out of the vulnerable range.

Change

The node_modules/follow-redirects entry in openam-ui/openam-ui-ria/package-lock.json: 1.16.0 → 1.16.1 (version, resolved, integrity). package.json is untouched — http-proxy asks for ^1.0.0, which 1.16.1 satisfies. No code change.

Verified:

• the lock file integrity matches npm view follow-redirects@1.16.1 dist.integrity
• node_modules/follow-redirects is the only follow-redirects entry in this lock file; the openam-ui-api and openam-ui-js-sdk lock files do not resolve it

References

• GHSA-8r9p-f939-6h3c
• GHSA-q3jh-wrc6-jgq8
• https://nvd.nist.gov/vuln/detail/CVE-2026-111755
• https://nvd.nist.gov/vuln/detail/CVE-2026-111756
• follow-redirects/follow-redirects@080a76d
• follow-redirects/follow-redirects@9865ca4
• https://github.com/follow-redirects/follow-redirects/releases/tag/v1.16.1