[GHSA-9pp5-9c7g-4r83] Spring Security authorization bypass for method security annotations on private methods #5747
+23
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updates
Comments
The vulnerability involves both spring-security-aspects and spring-security-core.
spring-security-aspects artifact is right to be flagged because the issue is only exploitable when that module (or @EnableMethodSecurity(mode = ASPECTJ)) is on the classpath.
On the other hand , the actual fix lives in spring-security-core, where the code that scans for security annotations is located. The patch changes a comparison from
if (method == candidate) { … }
to
if (method.equals(candidate)) { … }
Using equals() lets the scanner recognise the same method loaded by different class-loaders/AspectJ weaves, so the annotations are no longer skipped and the bypass is closed.
So to conclude, both packages should be flagged, also the fixing commit is in the core package which is anoth proof that this package is vulnerable. Moreover, to my understanding, if you use spring-security-core 6.4.5 and lower, even with the updated spring-security-aspects 6.4.6 you will still be vulnerable.