Affected

github.com/malcolmston/socketio <= v0.4.0. Parity case namespace-middleware-silent (group behaviour), recorded as divergence B4 in parity/socket.io/COVERAGE.md. Upstream oracle: socket.io@4.8.1 / socket.io-client@4.8.1 on Node v24.18.0.

Upstream vs port behaviour

Upstream nsp.use(fn) continues a handshake only when the middleware calls next(). A middleware that returns without calling either next() or next(err) leaves the handshake unanswered: the socket is never added to the namespace, no connection handler runs, and the client eventually surfaces a timeout connect error.

Namespace.runMiddleware in this port breaks out of the chain when next was not called but returns nil. A nil error is interpreted by the caller as "accepted", so the handshake is answered with CONNECT and the OnConnection handler runs.

Impact

This is an authentication bypass. "Decline silently / hold the handshake and decide later" is a standard auth-middleware shape — deliberately not calling next(err) so the client learns nothing about why it was refused:

nsp.Use(func(h *socketio.Handshake, next func(error)) {
    tok, ok := h.Auth["token"].(string)
    if !ok || !valid(tok) {
        return // deliberately silent: reject without leaking why
    }
    next(nil)
})

Against upstream this rejects the socket. Against this port it admits every socket, including sockets presenting no credential at all. The same failure mode is reached by any early return that forgets next(err): a panic/recover path, a ctx.Err() bail-out, or a return inside a validation branch. Every such path becomes an unconditional accept. The safe default for a middleware chain must be deny, not allow.

An unauthenticated remote attacker connecting to a namespace guarded this way is admitted with a live socket and full access to whatever the connection handler grants.

Repro

Register the middleware above on a namespace, then from a client:

sock, err := client.Dial(url+"/admin", client.Options{}) // no auth supplied

Upstream: Dial fails with a connect timeout. Port: Dial returns a live, joined socket.

Harness: GOWORK=off go test ./parity/socket.io/

Fix

In Namespace.runMiddleware, treat "chain terminated without next being called" as a failure. Match upstream by not answering the handshake at all, or at minimum return a non-nil error so the caller rejects the connection. Never return nil for a middleware that did not explicitly continue. Adding a regression test that asserts a silent middleware yields no connection event is advisable, since the current behaviour is indistinguishable from success at every layer above the chain.

Fixed

A fix has landed in the port's development tree (unreleased, > 0.4.0): Namespace.runMiddleware now returns a distinct errMiddlewareSilent sentinel when a middleware returns without calling next, and conn.handleConnect treats it as a denial that leaves the handshake unanswered (no CONNECT, no connection event) rather than an accept. Parity case namespace-middleware-silent now passes: a silent middleware yields no connection event and the client times out. The finding is retained for the record and for affectedVersions <= 0.4.0.

Affected

github.com/malcolmston/express <= 0.4.0 (all published versions). No fix released.

Parity cases: default404-miss, default404-miss-method (parity/express/cases/errors.json, harness in Malcolmston/go). Oracle: express 4.21.2.

Upstream vs port

Application.ServeHTTP terminates an unmatched request with:

res.Status(http.StatusNotFound).Send("Cannot " + req.Method() + " " + req.Path())

Response.Send defaults a string body to Content-Type: text/html; charset=utf-8 (response.go:145-148), and req.Path() is r.URL.Path, i.e. percent-decoded. The request target is therefore reflected, unescaped, into an HTML document.

Upstream express delegates to finalhandler, which HTML-escapes the path and sends Content-Security-Policy: default-src 'none' and X-Content-Type-Options: nosniff. The port sends neither header.

Impact (attacker terms)

Reflected XSS reachable on every application built on this module that does not install its own terminal 404 handler - which is the default, out-of-the-box configuration. The attacker needs only to get a victim to open a crafted URL on the target origin; there is no prerequisite application code, no authentication, and no unusual configuration. Script then runs in the application's origin with access to its cookies, tokens and same-origin API surface. The two response headers upstream sends exist precisely to make this class of bug unexploitable, and both are absent, so there is no defence-in-depth fallback.

Reproduction

app := express.New()
app.Get("/ok", func(req *express.Request, res *express.Response, next express.Next) { res.Send("ok") })

GET /%3Cimg%20src=x%20onerror=alert(1)%3E
-> 404, Content-Type: text/html; charset=utf-8
   body: Cannot GET /<img src=x onerror=alert(1)>

Upstream express 4.21.2 returns the same path HTML-escaped, under Content-Security-Policy: default-src 'none' and X-Content-Type-Options: nosniff.

Suggested fix

HTML-escape the reflected method and path (or send text/plain), and set X-Content-Type-Options: nosniff and Content-Security-Policy: default-src 'none' on both the default 404 path and finalError.

Severity rationale

Graded high: script execution in the application origin in the default configuration, requiring only a crafted URL, with both upstream mitigating headers missing. Not graded critical because the impact is client-side (no server-side code execution or data access) and requires victim interaction with an attacker-supplied URL.

Summary

sanitizehtml.Sanitize does not validate URL schemes at all. Upstream sanitize-html filters every URL-bearing attribute against allowedSchemes (http, https, ftp, mailto, tel) and drops the attribute when the scheme is not permitted. The port keeps the attribute verbatim, so a javascript: or data:text/html URL passes straight through into the sanitized output.

This is broader than an earlier draft of this finding stated. That draft claimed href, src and cite were scheme-checked and only the other sixteen attributes were missed. Direct execution against the published module disproves that: href is not checked either.

Verified against the published module

Reproduced against github.com/malcolmston/express@v0.4.0, the latest published version:

opts := sanitizehtml.Options{
    AllowedTags:       []string{"a"},
    AllowedAttributes: map[string][]string{"a": {"href"}},
}
sanitizehtml.Sanitize(`<a href="javascript:alert(1)">click</a>`, opts)
// => <a href="javascript:alert(1)">click</a>      (payload retained)

// Same for every other URL attribute, e.g.:
//   <button formaction="javascript:alert(1)">  with button[formaction] allowed
//   <video poster="javascript:alert(1)">       with video[poster] allowed

Upstream sanitize-html@2.17.6 returns <a>click</a> for the first case — attribute dropped, text kept.

Impact

Stored or reflected XSS in any application that uses this package to sanitize untrusted HTML and permits a URL-bearing attribute. A javascript: URL in an href executes on click; data:text/html navigates to attacker-controlled markup. The whole purpose of the package is to make such input safe, so a caller has no reason to filter schemes themselves.

Precondition, stated precisely

The caller must allow at least one URL-bearing attribute. The zero-value Options{} policy in v0.4.0 allows no tags at all and strips everything, so the literal default is not affected. But allowing a[href] is the canonical way to use an HTML sanitizer, and it is exactly what upstream permits in its OWN defaults — so this is normal, documented usage rather than an exotic configuration.

Scope note

This manifest deliberately no longer contains a nonTextTag raw-content finding. An earlier draft claimed an allowed <option>/<textarea> had its content emitted verbatim. Direct execution against v0.4.0 disproves it: Sanitize("<option><img src=x onerror=alert(1)></option>", Options{AllowedTags: []string{"option"}}) returns <option></option>, and the <textarea> case returns <textarea></textarea>. That defect existed only in the unreleased working tree, where nonTextTags handling was added, and was fixed there before release. It is not a disclosure.

Fix

The port now carries upstream's full allowedSchemes / allowedSchemesByTag / allowedSchemesAppliedToAttributes model and applies it to all nineteen URL-bearing attributes, with imagesrcset srcset-filtered.

Summary

RFC 7797 s3 requires b64 to be listed in crit, and s6 requires it to be integrity protected. The port reads b64 from the merged header (protected union unprotected), and checkCritical is also satisfied by the parameter's presence in merged. A crit:["b64"] in the protected header can therefore be satisfied by a b64 an attacker places in the unprotected header: the crit requirement, which exists precisely to prevent this, is neutralised by the same lookup that was meant to enforce it.

Parity case: rej-jws-b64-false-in-unprotected-with-crit (group reject).

Upstream vs port behaviour

Impact

crit is how a producer says "reject this token unless you understand and honour parameter X". Satisfying it from an attacker-controllable header means a verifier can be made to believe it honoured a critical parameter the signer never signed. Combined with b64's effect on payload interpretation, this yields the same keyless payload-substitution primitive as the companion advisory, but reached even on tokens whose signer did defend against it by naming b64 in crit.

Rated high: same integrity impact and same no-key precondition as the no-crit variant, and it additionally defeats an explicit producer-side mitigation. Restricted to the JSON serialization.

Root cause

jws.go at aa9e56a:

merged, err := mergeHeaders(protected, unprotected)      // :307
known := append([]string{"b64"}, opts.KnownCritical...)
if err := checkCritical(protected, merged, known); err != nil { ... }  // :322 - satisfied from merged
b64 := true
if v, present := merged["b64"]; present { ... }           // :327 - read from merged

Reproduction

{
  "payload": "SXQncyBhIGRhbmdlcm91cyBidXNpbmVzcywgRnJvZG8sIGdvaW5nIG91dCB5b3VyIGRvb3Iu",
  "signatures": [
    {
      "header": { "b64": false },
      "protected": "eyJhbGciOiJIUzI1NiIsImNyaXQiOlsiYjY0Il19",
      "signature": "ppChox5SDDSKjeO7hsCj_RuoNiq-FenHSY0bnCTqIus"
    }
  ]
}

protected decodes to {"alg":"HS256","crit":["b64"]}. Key (parity/jose/keys/oct-32.json): {"kty":"oct","k":"qbSot6YRXrsT-T9ytjbF654zxrkx9fTCCerXvJav324"}. VerifyJSON returns no error.

Suggested fix

checkCritical must be satisfiable only by parameters present in the protected header, and b64 must be read only from the protected header. A b64 in a shared unprotected or per-recipient header should be ErrInvalidHeader, not an input.

Note: the workspace working tree contains unreleased changes that appear to do this; no published version of the module contains them.

Affected version

github.com/malcolmston/jose at v0.0.0-20260810111536-aa9e56a9a81b (commit aa9e56a), the version resolved by go get github.com/malcolmston/jose@latest. No published version contains a fix.

Evidence / provenance

• Parity suite parity/jose (GOWORK=off go test ./parity/jose/), upstream pinned to jose@5.9.6 (panva/jose).
• Case parity 144/157 (91.7%); this case is listed in parity/jose/parity.json under failedCases, and deviations is 0, so this is not a sanctioned deviation. API-DEVIATIONS.md at aa9e56a does not list this behaviour.

Affected

github.com/malcolmston/passport <= v0.3.0, HTTP Digest strategy. Parity case digest-uri-replayed-at-other-path (group digest, in parity.json -> securityFindings). Upstream oracle: passport-http@0.3.0.

Upstream vs port behaviour

The port hashes the client-supplied uri directive into HA2 = MD5(method:uri) — so the digest arithmetic is correct — but never compares uri to the path actually requested. Upstream's strategy compares req.url with creds.uri and returns 400 on mismatch.

A header minted for /digest sent to /digest/other:

GET /digest/other
Authorization: Digest username="alice", realm="Parity",
  nonce="deadbeefdeadbeefdeadbeefdeadbeef", uri="/digest", qop=auth,
  nc=00000001, cnonce="0a4f113b", response="c96b08cf59227e7f0270c1ad0a8e214e"

parity/passport/COVERAGE.md records the row req.url === creds.uri binding as — (missing).

Impact

RFC 7616's uri directive exists to bind a digest response to one request target. The port never compares that directive to the path actually requested, so the response is not bound to a path. The binding it does keep is the method: HA2 = MD5(r.Method + ":" + params["uri"]) mixes in the real request method (digest.go:106), so a captured header only verifies when replayed with the same HTTP method. Cross-method replay therefore fails — a header minted for GET /digest will not authenticate a POST /digest/admin/delete, because the recomputed HA2 (using POST) no longer matches.

What does work is same-method, cross-path replay: a header captured from a harmless GET /digest — in a log, a proxy trace, a referrer — can be replayed against GET /digest/other, GET /digest/admin/list, or any other route reached with the same method that the strategy guards, because nothing in the hash the server verifies depends on where the request is actually going. Any GET-readable resource behind the strategy becomes reachable with one captured GET header. Combined with the absent replay protection (tracked separately), one captured header becomes a credential valid for every same-method route under the strategy.

It also fails in the other direction: an intermediary that rewrites the path can no longer be detected.

Repro

Mount two routes behind the same digest.New(...) strategy. Compute a valid header for route A and send it to route B; it authenticates with 200.

Harness: GOWORK=off go test ./parity/passport/

Fix

In digest.Strategy.Authenticate, compare the request target against creds.uri before accepting the response digest, and reject a mismatch (upstream uses 400; 401 is also defensible, but the check must exist). Important detail: compare against the request-target form the client actually hashed — path plus query string as sent — not a normalised or router-resolved form, or legitimate clients will break.

Status

Fixed in the working tree (unreleased). The serialiser now routes <title>/<textarea> through the escapable-raw-text path — &, <, > (and U+00A0) are re-escaped, and only the true raw-text elements <script>/<style> are written verbatim (dom.go). The parity case parse-raw-text now matches the cheerio oracle, and Page.HTML()/NormalizedHTML()/Element.OuterHTML()/InnerHTML() round-trip escapable-raw-text content safely. v0.2.0 remains affected because the fix has not yet been published; this finding is retained for the coordinated release of that fix. See puppeteer/API-DEVIATIONS.md.

Affected

github.com/malcolmston/puppeteer <= 0.2.0 (v0.2.0 is the only published release; the fix is in the working tree but not yet released).

Parity cases: parse-raw-text, parse-full-document, http-page-html (harness findings P8/P9 and H2 in parity/puppeteer/COVERAGE.md). Oracle: cheerio@1.0.0 (parse5 + dom-serializer).

Affected output paths, all sharing one root cause in the serialiser: Page.HTML(), Page.NormalizedHTML(), Element.OuterHTML(), Element.InnerHTML().

Mechanism

Ordinary text nodes are escaped correctly and round-trip fine — escapeText turns &→&, <→<, >→>, so a <div> (or <p>, <span>, …) holding text that came from decoded character references is re-emitted safely.

The defect is narrower and more dangerous. The serialiser (dom.go) puts the HTML "escapable raw text" elements — <title> and <textarea> — in the same verbatim branch as the true raw-text elements <script> and <style>:

// dom.go
var rawTextElements   = map[string]bool{"script": true, "style": true}
var escapableRawText  = map[string]bool{"textarea": true, "title": true}
...
case TextNode:
    if p := n.Parent; p != nil && p.Type == ElementNode &&
        (rawTextElements[p.Data] || escapableRawText[p.Data]) {
        sb.WriteString(n.Data)          // <-- written VERBATIM, no escaping
    } else {
        sb.WriteString(escapeText(n.Data))
    }

Writing <script>/<style> verbatim is correct (their content is CDATA-like and re-tokenised literally). Writing <title>/<textarea> verbatim is not: they are escapable raw text, so the parser decodes character references inside them on the way in, and the serialiser must re-escape & and < on the way out. Because it does neither, both & and < leak, turning what was escaped, inert text back into live markup — a sanitizer bypass.

Upstream vs port

Source <textarea>&lt;/textarea&gt;&lt;script&gt;alert(1)&lt;/script&gt;</textarea> — the escaped text of a comment/handle that should stay inside the textarea:

The same escaped content placed in a <div> is serialised correctly by the port (it goes through escapeText), which pinpoints the bug to the escapableRawText verbatim branch rather than to text handling in general. The plain-& case (<title>Doc &amp; Title</title> → <title>Doc & Title</title>) is the mild symptom of the same branch.

Impact (attacker terms)

Serialisation is the boundary where a DOM becomes markup again. Content that was inert, escaped text inside a <title> or <textarea> in the source document comes back out live. A scrape → cache → render pipeline built on Page.HTML() therefore converts harmless escaped user content that appears inside a <textarea>/<title> on a third-party page into a closed element followed by live script in its own output — a stored-XSS-enabling sanitizer bypass: whoever controls that page's user content can inject <script> (or any markup) into the consumer's origin. Round-tripping is not idempotent, the usual signature of an unsafe serialiser.

Impact is contingent on the consuming application rendering or forwarding the serialiser output as HTML — the normal use of the API, but one step removed from direct script execution. It only bites once the output is rendered as HTML.

Reproduction

const src = `<!doctype html><html><head><title>Doc &amp; Title</title></head>` +
	`<body><textarea>&lt;/textarea&gt;&lt;script&gt;alert(1)&lt;/script&gt;</textarea>` +
	`<div>&lt;script&gt;alert(2)&lt;/script&gt;</div></body></html>`

srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-Type", "text/html; charset=utf-8")
	fmt.Fprint(w, src)
}))
defer srv.Close()

b, _ := puppeteer.Launch(puppeteer.LaunchOptions{})
p, _ := b.NewPage()
p.Goto(srv.URL)
fmt.Println(p.HTML())

Observed — the <textarea> content escapes its element and becomes live, while the <div> is handled correctly:

... <textarea></textarea><script>alert(1)</script></textarea><div>&lt;script&gt;alert(2)&lt;/script&gt;</div> ...

Expected (what parse5/cheerio produce) — the <textarea> content stays escaped and inert:

... <textarea>&lt;/textarea&gt;&lt;script&gt;alert(1)&lt;/script&gt;</textarea><div>&lt;script&gt;alert(2)&lt;/script&gt;</div> ...

Suggested fix

Serialise <title> and <textarea> through the escapable-raw-text path, not the raw-text path: escape &→& and <→< (and U+00A0→ ) in their text, escaping & first. Only true raw-text elements (script, style) may be written verbatim. The escapableRawText set must be dropped from the verbatim branch of Node.render.

Severity rationale

Graded high. This is not a cosmetic escaping quirk: because <title>/<textarea> are serialised verbatim while the parser decodes references inside them, escaped attacker text is re-emitted as live markup, giving a sanitizer bypass that enables stored XSS in any consumer that renders Page.HTML()/OuterHTML() output as HTML. The one mitigating factor — impact is realised only once the output is rendered/forwarded as HTML, which is the normal use of the API — is why it is graded high rather than critical, not medium.

Affected

github.com/malcolmston/express <= 0.4.0 (all published versions). No fix released.

Parity case: basic-encoded-path (parity/express/cases/routing-basic.json). Oracle: express 4.21.2.

Upstream vs port

newRequest takes the routing path from the already-decoded r.URL.Path (request.go:40):

path: cleanPath(r.URL.Path),

Go's net/http decodes %2F to / in URL.Path, so a %2F that the client sent inside a single path segment becomes a segment separator before any route is matched.

Upstream matches on the raw (still-encoded) path via path-to-regexp and applies decodeURIComponent per captured parameter after the match.

Impact (attacker terms)

Percent-encoding a slash is the standard way to keep an untrusted value confined to one path segment. Decoding before routing means a value that was escaped specifically so it could not traverse into another route now does exactly that. This is an authorisation-bypass and path-confusion primitive rather than a cosmetic routing difference.

Precondition — this is not an unconditional auth bypass. A gate that inspects the decoded path is not bypassed: %2F has already become / in r.URL.Path, so an in-Express app.Use("/admin", requireAdmin) prefix guard sees the same decoded /admin/secret the router does and still fires. The bypass requires an authorization check made against the encoded / raw URL — one that decides on the request target before the port decodes it. Concretely:

• a reverse proxy, WAF, or CDN ACL whose rule matches the raw request target (/admin/secret) never sees that string, because the attacker sends /admin%2Fsecret;
• middleware that reads the raw path itself — e.g. req.Raw.URL.EscapedPath() or the path component of req.Raw.RequestURI — and gates on it;

any such raw-URL gate denies /admin/secret yet lets /admin%2Fsecret through, and the port then decodes %2F and routes the request into the /admin/secret handler (200), where upstream express 4.21.2 returns 404 (no match, req.url keeps %2F). The two components disagree about the same request — the raw-URL gate and the port's router reach opposite conclusions.

• Relatedly, /files/:name receiving name=a%2F..%2Fb yields a parameter that traverses segments, feeding path traversal into any handler that treats :name as a single opaque token.

Exploitability therefore depends on an authorization decision being made on the raw/encoded request target somewhere in front of the port's routing (a proxy, WAF, or raw-path middleware), or on a handler trusting a segment-scoped parameter as opaque — common deployments, but not universal, hence a primitive rather than a guaranteed bypass.

Reproduction

app := express.New()
app.Get("/a/b", func(req *express.Request, res *express.Response, next express.Next) { res.Send("HIT") })
// GET /a%2Fb  ->  200 "HIT"   (express 4.21.2: 404)

Suggested fix

Match against r.URL.EscapedPath() (falling back to the path component of RequestURI) and decode each captured parameter individually after the match, matching path-to-regexp + decodeURIComponent upstream.

Severity rationale

Graded medium (CVSS-style "moderate"): it reliably breaks a security-relevant invariant (segment escaping) and yields authorisation-bypass and traversal primitives, but realising impact requires the consuming application to rely on path-prefix guards or segment-scoped parameters. Lower than the default-404 XSS in the same module, which needs no cooperating application code.

Summary

jsonwebtoken.Verify accepts a token whose HMAC key is zero length, and Sign will mint one. Upstream jsonwebtoken@9.0.3 refuses both, because !secretOrPublicKey is falsy for an empty string/buffer and it throws "secretOrPrivateKey must have a value".

Impact

A deployment whose signing secret comes from configuration that resolves to empty — an unset environment variable, a missing secrets-manager key, a typo'd config path — does not fail. It silently signs and verifies with a zero-length key, which every party can reproduce, so anyone can mint an accepted token. Upstream turns the same misconfiguration into a startup error. The port converts a loud failure into a silent total authentication bypass.

Verified against the published module

Reproduced against github.com/malcolmston/express@v0.4.0 (the latest published version) with the real v0.4.0 API:

// forge() builds header.payload and HMAC-SHA256s it with the given key.
tok := forge("HS256", []byte(""))
claims, err := jsonwebtoken.Verify(tok, []byte(""))
// => claims non-nil, err == nil   (accepted)

Scope note

This manifest deliberately does NOT contain an algorithm-confusion finding. The published jsonwebtoken package in v0.4.0 is HMAC-only: SignOptions.Alg accepts only HS256/HS384/HS512, and Verify rejects a header alg of none, RS256 or lowercase hs256 outright with "unsupported algorithm" — verified by direct execution. There is no asymmetric verification path to confuse, so the public-key-as-HMAC-secret attack does not apply to any released version. That flaw exists only in the unreleased working tree, where asymmetric support and a VerifyOptions.Algorithms allowlist were added; it was fixed there before release (ErrAsymmetricKey, nil-vs-empty allowlist semantics) and so is not a disclosure.

Fix

Sign and Verify now return ErrMissingKey for a zero-length key.

Summary

semver.Parse stripped a leading = and accepted an uppercase V, both of which belong to node-semver's loose mode; its strict grammar is ^v? after a trim. Related leniencies in the same package: Coerce normalised a leading zero away (Coerce("01.02.03") returned "1.2.3" where upstream coerce returns null, because upstream re-parses the reassembled digits), and IncWith accepted an arbitrary prerelease identifier and could therefore emit a string that is not a valid version (IncWith("1.2.3", "prepatch", "bad id") returned "1.2.4-bad id.0" where upstream inc returns null).

semver.Valid("=1.2.3")   // port: true   upstream: valid("=1.2.3") === null
semver.Valid("V1.2.3")   // port: true   upstream: null
semver.Clean("V1.2.3")   // port: "1.2.3" upstream: null
semver.Coerce("01.02.03") // port: "1.2.3" upstream: null
semver.IncWith("1.2.3", "prepatch", "bad id") // port: "1.2.4-bad id.0"

Impact

Lower than the range finding, but it is still a validate-here/compare-there hazard. A service that validates an incoming version string with this package and then forwards it to a JavaScript component (an npm resolver, a registry client, a manifest writer) will accept identifiers the JavaScript side rejects — and, in the IncWith case, will produce a version string that no strict semver parser will accept, which can turn a released artefact name into something unparseable downstream. Where two components disagree about whether a string is a version, a version pin can be smuggled past one of them.

Repro

parity/express/nested/semver cases p-lead-eq, p-lead-V, cl-uppercase-v, co-leadzero and id-bad-identifier:

cd parity/express/nested/semver && GOWORK=off go test -run 'TestParity/(p-lead-eq|p-lead-V|cl-uppercase-v|co-leadzero|id-bad-identifier)$' .

Fix

Parse now strips only a single leading lowercase v after trimming. Clean keeps upstream's more permissive behaviour explicitly (trim, then strip any run of [=v]), which is where the =-prefixed spelling legitimately belongs. Coerce rejects a component with a leading zero, and IncWith validates the identifier against the prerelease-identifier grammar before using it.

Summary

semver.ParseRange never rejects its input. An unparseable field was degraded to the wildcard x rather than reported, so a constraint that node-semver refuses — "garbage", "latest", a tarball URL, or the comma spelling ">=1.0.0, <2.0.0" that npm does not accept — parsed successfully and then matched versions.

Actual measured behaviour

Reproduced against github.com/malcolmston/express@v0.4.0 (latest published):

"garbage"         parsed OK, matches 0.0.0 0.0.1 0.1.0 0.9.9   (not >= 1.0.0)
"latest"          parsed OK, matches 0.0.0 0.0.1 0.1.0 0.9.9
"^1.2.3"          parsed OK, matches nothing in that set

So a bogus range does NOT match every version: it degrades to a permissive 0.x-shaped constraint. An earlier draft of this finding claimed it collapsed to >=0.0.0 and admitted everything; direct execution disproved that, and the claim is corrected here rather than published.

Impact

Two concrete consequences, both of which need the caller to feed in a range that is wrong or externally influenced:

1. A gate that should have failed closed does not fail at all. A typo'd or externally supplied constraint yields no error, so a caller that checks err never learns the constraint was meaningless.
2. Pre-1.0 versions are admitted. Because the degraded range matches the whole 0.x line, a check meant to pin ^1.2.3 silently accepts 0.0.1. This is material in this ecosystem specifically: most malcolmston/* modules are themselves 0.x, so the admitted set is exactly the set in play.

Severity is medium, not high: the range must already be invalid for this to trigger, and the degraded range is more restrictive than "everything".

Fix

range.go gained a strict XRANGEPLAIN parser (semParsePartial) plus upstream's invalidXRangeOrder rule, so an unparseable range now returns an error instead of degrading to a wildcard.

Summary

In the JWS general/flattened JSON serialization, the port reads the b64 header parameter (RFC 7797) from the merged protected-plus-unprotected header. The unprotected header is not covered by the signature, so anyone who can see a valid JWS can add {"b64":false} to it. The MAC/signature still verifies, but the port then returns the undecoded base64url text of the payload instead of the payload itself. An attacker with no key changes the byte string a verifying application receives.

Parity case: rej-jws-b64-false-in-unprotected-no-crit (group reject).

Upstream vs port behaviour

Upstream jose@5.9.6 reads b64 from parsedProt only (jws/flattened/verify.js), so an unprotected copy is ignored and the payload is decoded as signed.

Impact

Signature verification is supposed to bind the payload the caller receives to the payload the signer signed; here it does not. An attacker who obtains a valid JWS (from a log, a header, a message queue) and who cannot forge any signature can still change the bytes the relying application consumes by appending a five-character member to an unprotected header. Anything that verifies and then parses the returned payload — claims, a webhook body, a capability document — can be made to see different bytes than were signed, while verification reports success so nothing downstream can detect it.

Rated high: no key material is needed and integrity of an authenticated message is broken, but exploitation requires the JSON serialization (not compact JWS) and the resulting substitution is constrained to "encoded text instead of decoded payload" rather than attacker-chosen plaintext.

Root cause

jws.go at aa9e56a, JSON verification path:

merged, err := mergeHeaders(protected, unprotected)   // jws.go:307
...
b64 := true
if v, present := merged["b64"]; present {             // jws.go:327  <-- merged, not protected

b64 decides how an authenticated octet string is interpreted, so it must come from the protected header only. RFC 7797 s6 requires it to be integrity protected.

Reproduction

Document below is an ordinary, correctly signed HS256, b64:true JWS; only the header (unprotected) member was added by the attacker.

{
  "payload": "SXQncyBhIGRhbmdlcm91cyBidXNpbmVzcywgRnJvZG8sIGdvaW5nIG91dCB5b3VyIGRvb3Iu",
  "signatures": [
    {
      "header": { "b64": false },
      "protected": "eyJhbGciOiJIUzI1NiJ9",
      "signature": "SHOZXfrz9Xd5D1CyX-xk-GrGGQEuwrjXyxA6aCrsT9E"
    }
  ]
}

Key (parity/jose/keys/oct-32.json): {"kty":"oct","k":"qbSot6YRXrsT-T9ytjbF654zxrkx9fTCCerXvJav324"}

jwk, _ := jose.ParseJWK([]byte(`{"kty":"oct","k":"qbSot6YRXrsT-T9ytjbF654zxrkx9fTCCerXvJav324"}`))
pl, hdr, err := jose.VerifyJSON(doc, jwk)
// err == nil; hdr["b64"] == false; pl is the base64url text, not the payload

Suggested fix

Read b64 from the protected header only, and reject a b64 appearing in a shared unprotected or per-recipient header with ErrInvalidHeader rather than honouring it. See also the companion advisory where an unprotected b64 also satisfies crit (rej-jws-b64-false-in-unprotected-with-crit).

Note: the workspace working tree contains unreleased changes that appear to implement exactly this (jws.go reading protected["b64"] and rejecting unprotected["b64"]); no published version of the module contains them.

Affected version

github.com/malcolmston/jose at v0.0.0-20260810111536-aa9e56a9a81b (commit aa9e56a), the version resolved by go get github.com/malcolmston/jose@latest. No published version contains a fix.

Evidence / provenance

• Parity suite `parity/

Summary

RFC 7517 s4.4 lets a JWK pin itself to one algorithm. The port treats JWK.Alg only as a default for SignOptions.Algorithm and never checks it for conflict, so a key pinned to "alg":"HS512" is used with a header alg of HS256, for both signing and verification. Upstream refuses.

Parity cases: rej-jws-jwk-alg-mismatch-sign, rej-jws-jwk-alg-mismatch-verify (group reject).

Upstream vs port behaviour

Key (parity/jose/keys/oct-32-alg-hs512.json):

{"kty":"oct","k":"qbSot6YRXrsT-T9ytjbF654zxrkx9fTCCerXvJav324","alg":"HS512"}

Verify case uses the HS256 token eyJhbGciOiJIUzI1NiJ9.SXQncyBhIGRhbmdlcm91cyBidXNpbmVzcywgRnJvZG8sIGdvaW5nIG91dCB5b3VyIGRvb3Iu.SHOZXfrz9Xd5D1CyX-xk-GrGGQEuwrjXyxA6aCrsT9E.

Impact

Also a missing enforcement / defence-in-depth gap rather than a signature bypass: the correct key is still required, and the accepted algorithms remain within the same key family (HS512 -> HS256, RS512 -> RS256), so this is a strength downgrade, not cross-family algorithm confusion. Rated moderate — higher than the use/key_ops gaps because alg pinning is specifically the mitigation that survives a caller who forgot to pass an algorithm allowlist, and here the choice of algorithm is silently handed back to whoever wrote the token header, with the returned header reporting the attacker's choice and no error or warning.

Root cause

JWK.Alg is consulted only to fill in an empty SignOptions.Algorithm; no conflict check exists at aa9e56a.

Reproduction

jwk, _ := jose.ParseJWK([]byte(`{"kty":"oct","k":"qbSot6YRXrsT-T9ytjbF654zxrkx9fTCCerXvJav324","alg":"HS512"}`))
tok, err := jose.Sign([]byte("hello"), jwk, jose.SignOptions{Algorithm: jose.HS256})
// err == nil, tok has {"alg":"HS256"}

Suggested fix

Compare JWK.Alg against the algorithm actually in use before every operation; mismatch -> ErrInvalidKey. On the JWS side the match must be exact. On the JWE side either the key management alg or the content encryption enc legitimately satisfies the member (RFC 7520 s5.6 publishes an oct key with "alg":"A128GCM" used with "alg":"dir").

Note: an unreleased checkJWKUsage (jwk.go:317) in the workspace working tree implements this; no published version has it, though API-DEVIATIONS.md already claims it does.

Affected version

github.com/malcolmston/jose at v0.0.0-20260810111536-aa9e56a9a81b (commit aa9e56a), the version resolved by go get github.com/malcolmston/jose@latest. No published version contains a fix.

Evidence / provenance

• Parity suite parity/jose (GOWORK=off go test ./parity/jose/), upstream pinned to jose@5.9.6 (panva/jose).
• Case parity 144/157 (91.7%); this case is listed in parity/jose/parity.json under failedCases, and deviations is 0, so this is not a sanctioned deviation. API-DEVIATIONS.md at aa9e56a does not list this behaviour.

Summary

jwt.WithValidMethods([]string{}) should permit nothing. The port treats an empty slice as "option not set" and applies no algorithm restriction at all, accepting for example an HS256 token. Upstream rejects everything for algorithms: [].

Parity case: alg-allowlist-empty (group algorithms).

Upstream vs port behaviour

Impact

Fails open, and silently. Allowlists are frequently computed: from config, from an environment variable split on commas, from a JWKS alg field, or from an intersection of "what this tenant permits" with "what this deployment supports". Any of those can produce an empty list — a missing env var, a typo, a tenant with no algorithms configured, an empty intersection. The caller's code reads as "restrict to exactly this set"; the effect is "impose no restriction", i.e. accept every registered algorithm — precisely the state that makes the algorithm-confusion issue (tracked separately) reachable.

Rated moderate: on its own it does not accept any token the library would not accept with no allowlist argument at all, and it requires the application to compute an empty allowlist. Its severity comes from being the silent enabler of the algorithm-confusion path rather than from direct exploitation.

Root cause

parser.go:

if len(p.validAlgs) > 0 && !contains(p.validAlgs, alg) {   // parser.go:183
    return token, fmt.Errorf("%w: alg %q is not accepted", ErrSignatureInvalid, alg)
}

len(p.validAlgs) > 0 conflates "no allowlist configured" with "an allowlist that permits nothing".

Reproduction

Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MDAwMDM2MDAsImlhdCI6MTcwMDAwMDAwMH0.uSyiX6mW2QalXyp6PI6h2UsPl323b6Mz8hggXGyW0rw, HMAC secret parity-hmac-secret-256-bits-long-enough.

tok, err := jwt.Parse(token, keyfunc,
    jwt.WithValidMethods([]string{}),
    jwt.WithTimeFunc(func() time.Time { return time.Unix(1700000100, 0) }))
// err == nil - the empty allowlist imposed nothing

Suggested fix

Track "was the option supplied" separately from the slice length — e.g. a validAlgsSet bool, or have WithValidMethods store a non-nil empty slice and test p.validAlgs != nil. An empty allowlist must reject every token.

Affected version

github.com/malcolmston/jwt at v0.3.0 (published module). No published version contains a fix.

Evidence / provenance

• Parity suite parity/jwt (GOWORK=off go test ./parity/jwt/), upstream pinned to jsonwebtoken@9.0.2 (auth0/node-jsonwebtoken).
• Case parity ~92.8%; this case is listed in parity/jwt/parity.json under mismatchedCases and is not one of the 3 declared deviations.
• All verification cases pin the clock (clockTimestamp upstream, jwt.WithTimeFunc in the port), so nothing here depends on wall time.

Summary

The classic algorithm-confusion attack. An attacker takes the RSA public key PEM a service publishes, uses its raw bytes as an HMAC secret, and signs an {"alg":"HS256"} token. A verifier that hands jwt.Parse those PEM bytes from its Keyfunc and passes no algorithm allowlist accepts the forged token. Upstream jsonwebtoken@9.0.2 rejects it.

Parity case: alg-confusion-hs-token-pem-secret-no-allowlist (group algorithms).

Upstream vs port behaviour

Upstream verify.js calls crypto.createPublicKey(secretOrPublicKey); when that succeeds it sets options.algorithms to the RSA/PSS set, so an HS256 header can never match. The port performs no such inference: with no WithValidMethods, any registered alg in the header is honoured and SigningMethodHMAC accepts whatever []byte it is handed.

Impact

The RSA public key is by definition public — served from a JWKS endpoint or committed as a .pem. An attacker who can read it can mint tokens with arbitrary sub, roles and exp and have them accepted as genuine: full authentication bypass for an affected service.

Rated high, not critical, because two application-side preconditions must both hold: the caller passes no WithValidMethods allowlist, and the Keyfunc returns raw key material as []byte rather than a typed key. Both mitigations are confirmed working by adjacent parity cases, so this is a missing safety inference rather than a broken cryptographic primitive:

• alg-confusion-hs-token-rs-allowlist — with jwt.WithValidMethods([]string{"RS256"}), both libraries reject.
• alg-confusion-hs-token-rsa-pubkey-no-allowlist — returning a typed *rsa.PublicKey from the Keyfunc, both reject (the port via ErrInvalidKeyType).

Note that the naive one-to-one port of jwt.verify(tok, pubPem) produces exactly the vulnerable shape, and upstream silently protected that caller.

Reproduction

Forged token (HMAC key = the literal bytes of parity/jwt/keys/rsa-2048.pub.pem):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MDAwMDM2MDAsImlhdCI6MTcwMDAwMDAwMCwic3ViIjoiYXR0YWNrZXIifQ.AlobPGdy1Vq7VLsN2P9oz3DC0phkPddsglG5gC1Oxi4

pem, _ := os.ReadFile("rsa-2048.pub.pem")
tok, err := jwt.Parse(forged, func(*jwt.Token) (any, error) { return pem, nil },
    jwt.WithTimeFunc(func() time.Time { return time.Unix(1700000100, 0) }))
// err == nil, tok.Claims["sub"] == "attacker"

Suggested fix

Infer an algorithm restriction from the key material when no allowlist was given: if the Keyfunc returns bytes that parse as a PEM/DER public or private key, restrict the acceptable alg set to the matching asymmetric family and refuse HS*. At minimum, refuse a []byte key beginning with -----BEGIN and document that WithValidMethods is mandatory.

Affected version

github.com/malcolmston/jwt at v0.3.0 (published module). No published version contains a fix.

Evidence / provenance

• Parity suite parity/jwt (GOWORK=off go test ./parity/jwt/), upstream pinned to jsonwebtoken@9.0.2 (auth0/node-jsonwebtoken).
• Case parity ~92.8%; this case is listed in parity/jwt/parity.json under mismatchedCases and is not one of the 3 declared deviations.
• All verification cases pin the clock (clockTimestamp upstream, jwt.WithTimeFunc in the port), so nothing here depends on wall time.

Affected

github.com/malcolmston/nodemailer <= v0.0.0-20260810111553-311143ed3171, Message.SetSubject. Parity case subject-with-newline (parity/nodemailer/cases/subject.json), recorded as divergence 2 ("Header injection through subject") in parity/nodemailer/COVERAGE.md. Upstream oracle: nodemailer@6.9.16.

Upstream vs port behaviour

Message.SetSubject writes the supplied value into the Subject: header verbatim, CRLF included. A subject containing \r\n therefore terminates the header field, and everything after it becomes a new header field of the composed message.

Given the subject "Innocent\r\nX-Injected: yes":

The harness canonicaliser parses both messages with the same parser, so this appears as a genuine extra header on the Go side, not as a formatting artefact.

Impact

This is the classic email-header-injection sink (CWE-93). Subjects are frequently attacker- or user-controlled: ticket titles, "someone commented: <their text>", order references, search terms echoed back in a notification. Any such value reaching SetSubject lets the submitter write arbitrary message headers, which is enough to:

• add Bcc: or extra To: recipients and exfiltrate the message body — typically containing a password-reset link, an invoice, or account data — to an address of their choosing;
• overwrite Reply-To and adjacent fields to redirect replies;
• inject a blank line and therefore an entire forged body / MIME structure after the header block.

Graded moderate rather than high because exploitation requires the embedding application to pass untrusted input through to a subject (or another header value); the library on its own is not remotely reachable. Where that data flow exists, impact is significant.

RFC 5322 forbids bare CR/LF in a field value at all, so no legitimate input is broken by fixing this.

Repro

m := nodemailer.NewMessage()
m.SetFrom("a@example.com")
m.AddTo("b@example.com")
m.SetSubject("Innocent\r\nX-Injected: yes")
m.SetText("hello")
b, _ := m.Build()
fmt.Printf("%s", b)   // output contains a line "X-Injected: yes"

Harness: cd parity/nodemailer/node && npm install && cd .. && GOWORK=off go test ./...

Fix

Sanitise before encoding, in SetSubject and in every other header-value path — AddHeader, display names, Message-ID, In-Reply-To, References, attachment filenames. Strip or fold bare \r and \n. Upstream folds: replace the CRLF with a fold (CRLF + WSP) or a single space so the payload remains inside the field value; that also keeps parity. Returning an error would be defensible, but folding matches upstream. A single shared header-value sanitiser applied at the encoding boundary is preferable to per-setter checks, so future setters cannot reintroduce the sink.

Affected

github.com/malcolmston/passport <= v0.3.0, HTTP Digest strategy (strategies/digest). Parity case digest-replay-same-nonce-nc (group digest, listed in parity.json -> securityFindings). Upstream oracle: passport-http@0.3.0 on passport@0.7.0.

Summary of the corrected claim

The port's Digest strategy provides no replay protection: an identical Authorization header (same nonce, same nc, same response) is accepted every time it is presented. That behaviour reproduces. However — and this is the correction to an earlier, overstated draft — this is a documented limitation and a missing hardening seam, not a divergence from a secure default:

1. The strategy already documents the absence of replay protection, verbatim, in its package doc comment.
2. It can be mitigated by a deployment without patching the library.
3. Bare upstream passport-http with no validate callback also accepts the same replay; upstream only rejects it because the parity harness happens to supply a validate hook. The genuine port-specific gap is therefore narrow: the port offers no validate / nonce seam at all, so a deployment cannot opt in to the protection the way an upstream deployment can.

What the port does (verified in source)

digest.go computes and constant-time-compares the response digest and nothing else. There is no nonce ledger and no nc tracking:

ha2 := md5hex(r.Method + ":" + params["uri"])
// response recomputed from ha1, nonce, nc, cnonce, qop, ha2 and compared;
// (nonce, nc) is never recorded, so the same pair verifies repeatedly.

Presenting the same header twice against the same route yields 200 both times.

This is explicitly documented in the digest package doc comment (digest.go):

SIMPLIFICATION and security caveats: this implementation does NOT track issued nonces, nonce counts (nc), or opaque values, so it does not defend against replay attacks and it accepts any well-formed nonce echoed by the client. ... layer it over TLS and, for real replay protection, add server-side nonce/nc bookkeeping.

So the doc comment already tells integrators (a) that replay is not defended, and (b) how to defend it (add server-side nonce/nc bookkeeping).

Upstream comparison — corrected

The earlier draft implied upstream rejects replay by default and the port is uniquely broken. That is not accurate:

The 401 upstream produced in the harness came from the harness's own validate hook, not from a built-in default check. Upstream's default (no validate) behaves like the port. The real, narrower divergence is that upstream exposes a validate seam an app can use to reject spent (nonce, nc) pairs, and the port exposes no such seam (its Options are only Realm, Secret, Nonce).

Control case digest-replay-incremented-nc accepts on both sides with a legitimately fresh nc=00000002 and recomputed response, confirming the divergence is specifically the replay, not the digest arithmetic.

Impact

Digest's defence against a passive observer is the one-shot nature of (nonce, nc). With neither a nonce ledger nor a seam to add one, any party who observes one Authorization header — a proxy log, an access log that records request headers, a mirrored packet, a TLS-terminating load balancer — can replay that exact header and be authenticated as the user without learning the password, for as long as the strategy runs with the same nonce policy.

The exposure is real but bounded by two facts the corrected narrative must keep straight: the limitation is documented, and it is mitigable at the application layer without patching. An integrator can wrap the strategy in outer middleware that records each accepted (nonce, nc) pair and rejects a repeat before (or after) the strategy runs — no library change required. The strategy also documents that it should be layered over TLS, which removes the passive-observer vector for the common deployment.

Mitigation available today (no patch)

// Application-layer replay ledger wrapping the digest strategy.
var seen sync.Map // key: nonce+":"+nc

func replayGuard(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		if p := parseDigest(r.Header.Get("Authorization")); p != nil {
			key := p["nonce"] + ":" + p["nc"]
			if _, dup := seen.LoadOrStore(key, struct{}{}); dup {
				w.Header().Set("WWW-Authenticate", `Digest realm="...", nonce="...", qop="auth"`)
				http.Error(w, "stale", http.StatusUnauthorized)
				return
			}
		}
		next.ServeHTTP(w, r)
	})
}

Repro

Send the identical header twice to the same route; both return 200.

Harness: GOWORK=off go test ./parity/passport/

Suggested fix

Add the seam upstream exposes, so replay defence becomes possible (ideally the default): an optional Options.Validate func(nonce, cnonce, nc, opaque string) (bool, error), or a NonceStore interface, invoked before the credential check. Shipping a default implementation that records issued nonces and rejects a non-increasing nc would move the secure behaviour from "add it yourself in outer middleware" to "on by default". The doc comment already states the current limitation plainly, so no documentation change is needed — the gap is the missing API seam, not missing disclosure.

Severity rationale

Downgraded to medium. The replay reproduces and has genuine confidentiality/authentication impact against a passive observer, which keeps it a real weakness rather than a non-issue. But three factors that an earlier draft got wrong pull it below the original "high": the behaviour is (1) documented in the package doc comment, (2) mitigable at the application layer without patching the library, and (3) shared with bare upstream passport-http (which also accepts the replay when no validate hook is supplied) — the port-specific defect is only the absence of a validate/nonce seam to opt into protection, not a broken default check.

Affected

github.com/malcolmston/socketio <= v0.4.0, decoder / binary reconstructor (socketio.Reconstruct, Decoder.Pending). Parity cases dec-binary-placeholder-out-of-range and dec-binary-zero-attachments (group wire-decode), recorded as divergences W8 and W9 in parity/socket.io/COVERAGE.md. Upstream oracle: socket.io-parser@4.2.7 (from socket.io@4.8.1), Node v24.18.0.

Upstream vs port behaviour

Upstream's binary reconstructor validates placeholder indices against the attachment list and throws Error: illegal attachments when they do not line up. This port's Reconstruct performs no such check and leaves the placeholder object in the decoded payload.

dec-binary-placeholder-out-of-range

Header declares one attachment; the placeholder asks for index 3:

51-["b",{"_placeholder":true,"num":3}]
<binary 00>

dec-binary-zero-attachments (same validation gap)

50-["b"]

Impact

A remote peer fully controls both the placeholder index and the declared attachment count, so this is remotely triggerable by any connected client with no special privileges. Handing an attacker-shaped map[string]any{"_placeholder": true, "num": 3} to a handler that expected []byte is a type-confusion primitive:

• b := args[0].([]byte) panics — a remote denial of service if the panic is not recovered per-connection;
• json.Marshal(args[0]) or similar persists or forwards the placeholder object downstream as though it were user data.

Because nothing errors, the malformed frame is indistinguishable from a valid one at every layer above the parser. Upstream's entire defence here is that the parser refuses the frame. Graded moderate: the impact is DoS / data-shape corruption in the application layer rather than a direct authentication or confidentiality break, and it depends on how the handler treats its arguments.

Repro

d := socketio.NewDecoder()
d.Add(`51-["b",{"_placeholder":true,"num":3}]`)
pkt, err := d.Add([]byte{0x00})
fmt.Println(pkt.Args(), err) // port: [map[_placeholder:true num:3]] <nil>
                            // upstream: throws "illegal attachments"

Harness: GOWORK=off go test ./parity/socket.io/

Fix

In Reconstruct, reject any placeholder whose num is < 0 or >= len(attachments), and reject a BINARY_EVENT / BINARY_ACK header whose declared attachment count is 0 — both with an error, never a pass-through. Also ensure Decoder.Pending reports correctly for a 0- attachment header rather than treating the packet as complete.

Fixed

A fix has landed in the port's development tree (unreleased, > 0.4.0): Reconstruct/reconstruct now return an error and reject any placeholder whose num is < 0 or >= len(attachments); DecodePacket rejects a BINARY_EVENT/BINARY_ACK header declaring 0 attachments; and the streaming Decoder, the server (conn.handleBinaryAttachment) and the client (Client.handleBinaryAttachment) all drop such frames instead of dispatching a raw placeholder object. Parity cases dec-binary-placeholder-out-of-range and dec-binary-zero-attachments now pass. The finding is retained for the record and for affectedVersions <= 0.4.0.

Affected

github.com/malcolmston/streamlit <= 0.3.0 (all published versions). No fix released.

Parity case: widget-hidden-then-shown (group widget-values, parity/streamlit/). Oracle: PyPI streamlit==1.61.1 via AppTest.

The non-sensitive correctness half of the same root cause - hidden widgets keeping stale values - remains tracked publicly as Malcolmston/streamlit#9. The resource-exhaustion half below was moved here.

Upstream vs port

Widget state is never pruned. The released Session in v0.3.0 has no seen set and no pruneStaleWidgets at all. The widget-state map is keyed by client-supplied strings taken from the body of POST /api/run, and entries are never removed, so every unknown key a client sends is retained for the life of the session.

Upstream Streamlit discards widget state once a widget stops being rendered, which bounds the map to the widgets the script actually draws.

Impact (attacker terms)

Untrusted input drives unbounded server-side memory growth, with no cap and no eviction. Anyone who can reach POST /api/run can add arbitrarily many keys to their session's map, and they persist for the session's lifetime; repeating across sessions multiplies the footprint until the process is OOM-killed. This is denial of service / resource exhaustion only - no confidentiality or integrity impact, no code execution, no cross-tenant data exposure. The library's own API-DEVIATIONS.md already identifies this shape for the data cache ("An unbounded cache whose keys derive from user input grows until the process dies"); the widget map has the same shape and no such bound.

Reproduction

POST /api/run with {"state":{"<random-key-1>":1, "<random-key-2>":1, ...}} grows the session map by one entry per unknown key, permanently - no request rejects the unknown keys and nothing later removes them.

That no pruning happens at all is independently observable through the correctness symptom:

func app(s *st.Session) {
	if s.Checkbox("show", true, "show") {
		s.TextInput("Name", "ada", "name")
	}
}

Set name to "grace", uncheck show, re-check it: the port returns "grace" where upstream 1.61.1 returns the declared default "ada".

Suggested fix

Prune widget state to the set of widgets rendered in the current run and reject or bound keys that no widget has ever declared - pruning by "seen this run" alone still lets never-rendered client-supplied keys accumulate. Add a hard per-session cap.

Note: the unreleased working tree already adds a seen set and pruneStaleWidgets, which addresses the stale-value half; the unknown-key growth half must be verified explicitly against that change before it is relied on as a fix.

Severity rationale

Graded low: real, untrusted-input-driven and unauthenticated - but availability only, scoped to the memory of sessions the attacker himself opens, and mitigable operationally with session limits and process memory caps. Deliberately not inflated to match the XSS findings in the sibling ports.

Summary

github.com/malcolmston/express/contenttype's Parse used the pattern "(?:\\.|[^"\\])*" for the quoted-string body of a Content-Type parameter. That character class is "anything that is not a quote or a backslash", which admits every control character: CR, LF, HTAB and NUL included.

The npm package this ports, content-type@1.0.5, restricts the quoted-string body to %x0b, %x20-21, %x23-5b, %x5d-7e and obs-text %x80-ff (its PARAM_REGEXP), and throws a TypeError for anything else. So where upstream refuses to parse, the port succeeded and handed the caller a parameter value containing the control bytes.

Impact

A parameter value is routinely copied back out — into a response header, a log line, a filename, a stored record. A value carrying \r\n is a header-splitting primitive if it reaches a sink that does not re-validate; a value carrying NUL is a truncation primitive in anything that later crosses into a C string. The port was the component whose job it was to reject that input, and it did not.

Severity is low rather than high because the most common source of a Content-Type value in a Go program is net/http, which rejects CR and LF in inbound header values before a handler ever sees them, and because Go's own http.Header.Set will not emit a header containing them. The exposure is real but indirect: values that reach Parse from somewhere other than an http.Request — a multipart part header, a database column, a config file, a proxied upstream response body — were not filtered.

Upstream vs port

input:  text/html; charset="utf-8\r\nX-Injected: 1"

content-type@1.0.5:  throws TypeError: invalid parameter format
port (<= 0.4.0):     ContentType{Type: "text/html",
                                  Parameters: {"charset": "utf-8\r\nX-Injected: 1"}}

Repro

The finding was produced by the nested parity harness, which runs both implementations over the same inputs:

$ cd parity/express/nested/contenttype/node && npm install
$ cd .. && GOWORK=off go test .
--- FAIL: TestParity/p-quoted-with-crlf
    ok mismatch: upstream ok=false (invalid parameter format), go ok=true ()

The four case ids above are in cases/parse.json.

Fix

Parse's parameter pattern now uses upstream's character class verbatim, and Format's output check uses upstream's TEXT_REGEXP (%x0b, %x20-7e, %x80-ff) — the port previously allowed HTAB there and disallowed vertical tab, which was wrong in both directions. Tabs are also no longer accepted as parameter padding, matching upstream's spaces-only ; *name *= *value * grammar. All 76 parity cases now match. Regression vectors for the rejected control characters were added to the package's edge_test.go and contenttype_parity_test.go.

Summary

semver.Sort, semver.Compare and the GT/GTE/LT/LTE/EQ/NEQ wrappers call MustParse and therefore panic on an invalid version string. Upstream's equivalents throw a catchable TypeError, which in JavaScript is routinely caught; in Go an unrecovered panic in a goroutine takes the whole process down.

semver.Sort([]string{"1.2.3", "nope"}) // panics: semver: invalid version

Impact

Denial of service where the version list is attacker-influenced — sorting the tags returned by a remote registry, ordering versions parsed out of an uploaded manifest, comparing a client-supplied X-App-Version header. net/http recovers a panic for the serving goroutine, but a panic in any other goroutine (a background reindexer, a worker pool) terminates the process.

This is documented behaviour ("Invalid strings cause a panic; validate untrusted input first"), and the panicking spelling exists deliberately alongside the error-returning Parse/Valid/Satisfies, so it is reported as hardening rather than as a defect. It is listed here because the crash is reachable from a plausible attacker path and the safe alternative is not obvious at the call site.

Repro

Cases s-sort-invalid, c-invalid-left and b-eq-invalid in parity/express/nested/semver exercise it; the Go runner has to recover() to report the case at all.

Suggested mitigation

Either add error-returning siblings (SortStrings([]string) error, CompareStrings(a, b string) (int, error)) and document the Must* spellings as constant-only, or have Sort skip/sink unparseable entries the way MaxSatisfying already does.

Summary

RFC 7517 s4.3 key_ops enumerates the operations a JWK permits. A JWK whose key_ops is ["encrypt","decrypt"] signs and verifies a JWS without complaint in the port. Upstream refuses both.

Parity cases: rej-jws-jwk-key-ops-without-sign, rej-jws-jwk-key-ops-without-verify (group reject).

Upstream vs port behaviour

Key (parity/jose/keys/oct-32-keyops-encrypt.json):

{"kty":"oct","k":"qbSot6YRXrsT-T9ytjbF654zxrkx9fTCCerXvJav324","key_ops":["encrypt","decrypt"]}

Verify case uses eyJhbGciOiJIUzI1NiJ9.SXQncyBhIGRhbmdlcm91cyBidXNpbmVzcywgRnJvZG8sIGdvaW5nIG91dCB5b3VyIGRvb3Iu.SHOZXfrz9Xd5D1CyX-xk-GrGGQEuwrjXyxA6aCrsT9E.

Impact

As with use, this is a defence-in-depth failure, not a signature bypass — nothing verifies without the right key, and an attacker must already be able to steer key selection. Rated low.

key_ops is the finer-grained sibling of use and the one most often used to split a symmetric key's duties (e.g. a key distributed for content encryption only). Ignoring it removes the only machine-checkable statement of intent that travels with the key, so an encryption key harvested from a config or a JWKS becomes a MAC key producing tokens the port will verify. The port also accepts tokens upstream verifiers reject.

Root cause

JWK.KeyOps is parsed (jwk.go:41) and then never read at aa9e56a.

Reproduction

jwk, _ := jose.ParseJWK([]byte(`{"kty":"oct","k":"qbSot6YRXrsT-T9ytjbF654zxrkx9fTCCerXvJav324","key_ops":["encrypt","decrypt"]}`))
_, err := jose.Sign([]byte("hello"), jwk, jose.SignOptions{Algorithm: jose.HS256})
// err == nil

Suggested fix

Enforce key_ops on every operation; mismatch -> ErrInvalidKey. Keys with no key_ops stay unrestricted.

Note: an unreleased checkJWKUsage in the workspace working tree implements this; no published version has it, though API-DEVIATIONS.md already claims key_ops is enforced.

Affected version

github.com/malcolmston/jose at v0.0.0-20260810111536-aa9e56a9a81b (commit aa9e56a), the version resolved by go get github.com/malcolmston/jose@latest. No published version contains a fix.

Evidence / provenance

• Parity suite parity/jose (GOWORK=off go test ./parity/jose/), upstream pinned to jose@5.9.6 (panva/jose).
• Case parity 144/157 (91.7%); this case is listed in parity/jose/parity.json under failedCases, and deviations is 0, so this is not a sanctioned deviation. API-DEVIATIONS.md at aa9e56a does not list this behaviour.

Summary

RFC 7517 s4.2 makes use a JWK's declared purpose. A JWK carrying "use":"enc" is accepted by the port for both producing and verifying a JWS. Upstream refuses both.

Parity cases: rej-jws-jwk-use-enc-for-signing, rej-jws-jwk-use-enc-for-verifying (group reject).

Upstream vs port behaviour

Key (parity/jose/keys/oct-32-use-enc.json) — identical key material to oct-32.json, only use differs:

{"kty":"oct","k":"qbSot6YRXrsT-T9ytjbF654zxrkx9fTCCerXvJav324","use":"enc"}

Verify case uses the token eyJhbGciOiJIUzI1NiJ9.SXQncyBhIGRhbmdlcm91cyBidXNpbmVzcywgRnJvZG8sIGdvaW5nIG91dCB5b3VyIGRvb3Iu.SHOZXfrz9Xd5D1CyX-xk-GrGGQEuwrjXyxA6aCrsT9E.

Impact

This is a defence-in-depth / key-hygiene failure, not a signature bypass: no signature is forged or accepted without the correct key, and an attacker gains nothing unless they can already influence which key the application selects. Rated low for that reason.

The consequence is that key separation exists only in whatever application code remembers to enforce it. A service that publishes an encryption key in a JWKS, or holds one in config beside its signing key, reasonably assumes the library will not let that key be pressed into signature service; with the check absent, a key-selection bug, a kid collision, or an attacker-chosen kid in a JWKS lookup silently yields a usable signing/verification key. The port also accepts tokens upstream verifiers reject, so policy is applied inconsistently across a mixed-language deployment.

Root cause

JWK.Use is parsed into the struct (jwk.go:32) and never read anywhere else at aa9e56a — there is no usage check on any sign/verify/encrypt/decrypt path.

Reproduction

jwk, _ := jose.ParseJWK([]byte(`{"kty":"oct","k":"qbSot6YRXrsT-T9ytjbF654zxrkx9fTCCerXvJav324","use":"enc"}`))
tok, err := jose.Sign([]byte("hello"), jwk, jose.SignOptions{Algorithm: jose.HS256})
// err == nil; upstream refuses to sign with an "enc" key

Suggested fix

Check use before every sign, verify, encrypt and decrypt; a mismatch should be ErrInvalidKey. A key stating no use stays unrestricted.

Note: an unreleased checkJWKUsage (jwk.go:309) in the workspace working tree implements this; no published version has it. API-DEVIATIONS.md in the working tree already claims "JWK use, key_ops, and alg are enforced", which is untrue of every released version — so this is also a documentation defect.

Affected version

github.com/malcolmston/jose at v0.0.0-20260810111536-aa9e56a9a81b (commit aa9e56a), the version resolved by go get github.com/malcolmston/jose@latest. No published version contains a fix.

Evidence / provenance

• Parity suite parity/jose (GOWORK=off go test ./parity/jose/), upstream pinned to jose@5.9.6 (panva/jose).
• Case parity 144/157 (91.7%); this case is listed in parity/jose/parity.json under failedCases, and deviations is 0, so this is not a sanctioned deviation. API-DEVIATIONS.md at aa9e56a does not list this behaviour.

Affected

github.com/malcolmston/passport <= v0.3.0, bearer strategy (bearer.extractToken). Parity case bearer-two-token-locations (group bearer, in parity.json -> securityFindings). Upstream oracle: passport-http-bearer@1.0.1.

Upstream vs port behaviour

A request carrying a bearer token in two locations at once — the Authorization header and the access_token query parameter — is accepted by the port, which silently prefers the header. RFC 6750 section 2 forbids more than one token location, and upstream's multi-location guard fires before verification and returns 400.

GET /bearer?access_token=tok-alice
Authorization: Bearer tok-alice

parity/passport/COVERAGE.md records token extraction + multi-location guard -> bearer.extractToken as differs.

Impact

The guard is not RFC pedantry: "two tokens, one request" is the shape of a request-smuggling / inspection-bypass attack. Anything in front of the application that authorises on one location while the application authenticates on the other can be walked past — a WAF or API gateway that scope-checks or rate-limits the access_token query parameter (because it appears in the URL, which is what gateways inspect and log) while the port authenticates the header; a reverse proxy that strips or rewrites Authorization but leaves the query string intact.

Even with no proxy in the path, the token the port acted on and the token an operator sees in the access log can differ, so audit logs and incident response attribute the request to the wrong principal.

Severity is moderate rather than high: exploitation requires a specific front-end/back-end disagreement, and both tokens in the parity case are valid — this is a missing guard, not a direct authentication bypass on its own.

Repro

curl -H 'Authorization: Bearer tok-alice' 'http://localhost:PORT/bearer?access_token=tok-alice'
# port: 200 alice ; upstream: 400

The case deliberately uses the same token in both slots, so the divergence is purely the missing guard, not a precedence question.

Harness: GOWORK=off go test ./parity/passport/

Fix

In bearer.extractToken, count the locations in which a token was found — Authorization header, access_token query parameter, access_token form field (all three are already supported, per bearer-query-access-token and bearer-form-access-token) — and fail the request when the count exceeds one. Upstream answers 400; matching that status also resolves four adjacent status-code mismatches in the same parity group.