GHSA-5739-39V2-5754 Patch Review: Advisory Describes RSA1_5 Oracle, Referenced Diff Does Not Show the Fix

Vulnerability

GHSA-5739-39V2-5754 describes a timing side-channel in PHP JWE decryption when using RSAES-PKCS1-v1_5 (RSA1_5). The issue is consistent with a Bleichenbacher/Marvin padding oracle: decryption behavior leaks whether PKCS#1 v1.5 processing and subsequent validation succeeded, allowing a remote unauthenticated attacker to iteratively recover the Content Encryption Key (CEK). This class of flaw is rooted in observable differences across failure paths, including timing, error handling, and data-dependent processing after RSA private-key operations.

For JWE implementations, a robust fix normally requires eliminating distinguishable failure behavior in the RSA1_5 unwrap path, ensuring constant-time handling where feasible, and often replacing or deprecating RSA1_5 in favor of OAEP-based algorithms. The advisory establishes the vulnerability, but the supplied patch snippet does not expose the affected decryption code path itself.

Relevant references: GitHub Security Advisory, official patch reference, and third-party report.

Patch

The only provided diff content from the official patch reference is a change to phpstan-baseline.neon. The snippet removes two serializer-related baseline entries and adds numerous static-analysis suppressions for untyped Symfony console command properties. No supplied hunk touches RSA decryption, JWE key management, PKCS#1 v1.5 padding checks, exception normalization, or timing-equalization logic.

file: phpstan-baseline.neon
[VULNERABLE]
-
			message: "#^Method Jose\\Bundle\\JoseFramework\\Serializer\\JWESerializer\:\:getSupportedTypes\(\) return type has no value type specified in iterable type array\.$#"
			count: 1
			path: src/Bundle/Serializer/JWESerializer.php

[PATCHED]
-
			message: "#^Property Jose\\Component\\Console\\AddKeyIntoKeysetCommand\:\:\$defaultDescription has no type specified\.$#"
			count: 1
			path: src/Library/Console/AddKeyIntoKeysetCommand.php

From the evidence provided, this is build/tooling metadata churn rather than a demonstrable security remediation. If PR #652 contains additional commits or files not included in the supplied digest, those are necessary to assess whether the oracle was actually addressed.

Review

Pros

• The advisory clearly identifies a high-risk cryptographic side-channel affecting RSA1_5 JWE decryption and frames it in terms of Bleichenbacher/Marvin-style exploitation, which is technically credible and actionable.
• The official reference points to a concrete upstream pull request, giving maintainers a canonical location to inspect once the full code changes are available.
• If the upstream intent was to modify decryption behavior elsewhere in the PR, centralizing the fix in the library is preferable to pushing mitigations onto downstream applications.

Cons

• The supplied patch evidence does not show any change in the vulnerable code path. A phpstan baseline update cannot, by itself, remediate a timing oracle in RSA1_5 decryption.
• No provided diff demonstrates constant-time failure handling, CEK substitution, uniform exception behavior, or algorithm restrictions/removal for RSA1_5.
• Because the vulnerable behavior is timing-sensitive, verification requires code-level review of the unwrap/decrypt path and ideally regression tests or benchmarks showing indistinguishable failure modes. None are present in the supplied material.
• The mismatch between the advisory severity and the visible diff raises a traceability problem: engineers cannot validate that the referenced patch actually addresses the root cause.

Verdict

Partial fix.

Based strictly on the provided sources, the advisory is credible but the visible patch artifact is not sufficient to confirm remediation. The shown changes are unrelated static-analysis baseline edits, so the security fix is either absent from the supplied digest or not evidenced here. Engineers should not treat this patch snippet alone as proof that the Bleichenbacher/Marvin oracle has been closed.

Recommended follow-up is to inspect the full PR at the upstream patch reference and verify that the RSA1_5 decryption path now uses uniform error handling and timing-resistant processing, or that RSA1_5 support has been disabled/replaced. Until that is confirmed, deployments exposed to JWE RSA1_5 decryption should assume residual risk consistent with the advisory.