Security
Headlines
HeadlinesLatestCVEs

Headline

GHSA-9gp8-6cg8-7h34: Spring Security's spring-security.xsd file is world writable

The spring-security.xsd file inside the spring-security-config jar is world writable which means that if it were extracted it could be written by anyone with access to the file system.

While there are no known exploits, this is an example of “CWE-732: Incorrect Permission Assignment for Critical Resource” and could result in an exploit. Users should update to the latest version of Spring Security to mitigate any future exploits found around this issue.

ghsa
#vulnerability#git#java#maven

Skip to content

    • Actions

      Automate any workflow

    • Packages

      Host and manage packages

    • Security

      Find and fix vulnerabilities

    • Codespaces

      Instant dev environments

    • Copilot

      Write better code with AI

    • Code review

      Manage code changes

    • Issues

      Plan and track work

    • Discussions

      Collaborate outside of code

    • GitHub Sponsors

      Fund open source developers

*   The ReadME Project
    
    GitHub community articles
  • Pricing

Provide feedback

Saved searches****Use saved searches to filter your results more quickly

Sign up

  1. GitHub Advisory Database
  2. GitHub Reviewed
  3. CVE-2023-34042

Spring Security’s spring-security.xsd file is world writable

Moderate severity GitHub Reviewed Published Feb 6, 2024 to the GitHub Advisory Database • Updated Feb 6, 2024

Package

maven org.springframework.security:spring-security-config (Maven)

Affected versions

>= 6.1.1, <= 6.1.3

>= 6.0.4, <= 6.0.6

>= 5.8.4, <= 5.8.6

>= 5.7.9, <= 5.7.10

Patched versions

6.1.4

6.0.7

5.8.7

5.7.11

Description

Published to the GitHub Advisory Database

Feb 6, 2024

Related news

CVE-2023-44387: Incorrect permission assignment for symlinked files used in copy or archiving operations

Gradle is a build tool with a focus on build automation and support for multi-language development. When copying or archiving symlinked files, Gradle resolves them but applies the permissions of the symlink itself instead of the permissions of the linked file to the resulting file. This leads to files having too much permissions given that symlinks usually are world readable and writeable. While it is unlikely this results in a direct vulnerability for the impacted build, it may open up attack vectors depending on where build artifacts end up being copied to or un-archived. In versions 7.6.3, 8.4 and above, Gradle will now properly use the permissions of the file pointed at by the symlink to set permissions of the copied or archived file.