{
  "@id": "urn:uuid:2c996416-4d1e-4b1d-b6c4-144022165c0d",
  "role": "Document Creator",
  "author": "https://tuxcare.com",
  "version": 32,
  "@context": "https://openvex.dev/ns/v0.2.0",
  "timestamp": "2026-11-04T09:15:51.446651+00:00",
  "statements": [
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare",
          "identifiers": {
            "purl": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare"
          }
        }
      ],
      "timestamp": "2026-09-24T09:31:26.931840+00:00",
      "status_notes": "Vulnerability CVE-2007-1651 does not affect version 5.8.15.tuxcare of org.springframework.security:spring-security-config. not_affected \u2014 Target = Spring Security 5.8.15.tuxcare.1. The OpenID module and OpenID4JavaConsumer.java exist, so the vulnerable component is present in this project. However, the upstream fix for the CVE-2007-1651 / commit f5468087 issue is already applied: OpenID4JavaConsumer.endConsumption() clears the cached DiscoveryInformation from the HTTP session at line 136 (`request.getSession().removeAttribute(DISCOVERY_INFO_KEY);`), immediately after reading it (line 129) and before it is used for verification (line 147). This removal is exactly the one-line change the vendor patch introduced, and git history confirms upstream commit f5468087c2 (Luke Taylor, 2010) is the commit that added this line and is present in the target tree. Because the cached authentication artifact is deleted after a single use, a later replayed/forged callback finds no cached discovery info: the null-check at lines 130-133 then throws \"DiscoveryInformation is not available. Possible causes are lost session or replay attack\", so a logged-out user's session cannot be restored via a cached token. The pre-fix vulnerable pattern (read cached discovery info WITHOUT removing it) is not present in HEAD. The fix is upstream-authored (springsource.com domain), not a TuxCare backport, so the verdict is not_affected with justification code_not_present. The TuxCare work at HEAD (merge of JAVAELSCVE-1165) only updates oauth2/saml2 .gradle build files and is unrelated to OpenID. [VC re-run with claude-opus-4-8, prod prompt pin d46bd7a, 2026-09-16; Sonnet run failed the author gate (A2 onboarding-merge overclaim); applied manually after git verification]",
      "justification": "vulnerable_code_not_present",
      "vulnerability": {
        "name": "CVE-2007-1651"
      },
      "impact_statement": "not_affected \u2014 Target = Spring Security 5.8.15.tuxcare.1. The OpenID module and OpenID4JavaConsumer.java exist, so the vulnerable component is present in this project. However, the upstream fix for the CVE-2007-1651 / commit f5468087 issue is already applied: OpenID4JavaConsumer.endConsumption() clears the cached DiscoveryInformation from the HTTP session at line 136 (`request.getSession().removeAttribute(DISCOVERY_INFO_KEY);`), immediately after reading it (line 129) and before it is used for verification (line 147). This removal is exactly the one-line change the vendor patch introduced, and git history confirms upstream commit f5468087c2 (Luke Taylor, 2010) is the commit that added this line and is present in the target tree. Because the cached authentication artifact is deleted after a single use, a later replayed/forged callback finds no cached discovery info: the null-check at lines 130-133 then throws \"DiscoveryInformation is not available. Possible causes are lost session or replay attack\", so a logged-out user's session cannot be restored via a cached token. The pre-fix vulnerable pattern (read cached discovery info WITHOUT removing it) is not present in HEAD. The fix is upstream-authored (springsource.com domain), not a TuxCare backport, so the verdict is not_affected with justification code_not_present. The TuxCare work at HEAD (merge of JAVAELSCVE-1165) only updates oauth2/saml2 .gradle build files and is unrelated to OpenID. [VC re-run with claude-opus-4-8, prod prompt pin d46bd7a, 2026-09-16; Sonnet run failed the author gate (A2 onboarding-merge overclaim); applied manually after git verification]"
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare",
          "identifiers": {
            "purl": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare"
          }
        }
      ],
      "timestamp": "2026-09-24T09:31:26.931840+00:00",
      "status_notes": "Vulnerability CVE-2007-1652 is a false positive for org.springframework.security:spring-security-config 5.8.15.tuxcare. CVE-2007-1652 is a vulnerability in JanRain's myOpenID hosted service, on the OpenID\nProvider side. It does not apply to Spring Security in any version.\n\nNo affected software product is on record. The CVE record carries vendor \"n/a\", product\n\"n/a\" and version \"n/a\"; NVD lists a single unversioned CPE, cpe:2.3:a:openid:openid:*,\nwith no version bounds; the GitHub advisory GHSA-3x88-xvgr-m6fg is unreviewed and lists\nno affected package in any ecosystem; OSV has no entry for any spring-security artifact\n(control: the same query returns 5 entries for spring-security-config and 31 for\nspring-security-core); and spring.io publishes no advisory for this CVE. Every one of the\neight references points to JanRain's myOpenID security-fix announcement of March 2007 or\nto the openid.net security mailing list threads of the same month, where the reporter\nstates the problem had to be fixed on the myOpenID server.\n\nThe reported mechanism is Provider-side by construction. A crafted web page uses a cached\nauthentication token and an existing Provider session to forcibly log a user into an\nOpenID-enabled site, release the user's personal information to it, and silently add that\nsite to the user's trusted-sites list. A trusted-sites auto-approval list exists only at\nan OpenID Provider; a relying party has no such list and no auto-approval step at which\nthe flaw could occur.\n\nThe openid module of Spring Security implements only the relying-party (consumer) role.\nOpenIDAuthenticationFilter drives the two-leg consumer flow and OpenID4JavaConsumer wraps\nopenid4java's ConsumerManager. The only openid4java packages referenced in the tree are\nconsumer, discovery, message and association - there is no use of org.openid4java.server,\nno ServerManager, no OpenID Provider implementation, and no trusted-sites or auto-approval\nhandling of any kind. No openid4java sources are vendored into the tree.\n\nNor could this library have been affected when the issue was disclosed: the CVE was\npublished on 24 March 2007, while the earliest OpenID code in the project dates from\n20 April 2007 and only reached the shipped openid module in January 2008.\n\nResolved consistently with spring-security 5.6.10 (VPV 9976), 5.7.11 (43741),\n5.7.12 (12031), 5.7.14 (40534) and 5.8.16 (330), all closed as false_positive.",
      "vulnerability": {
        "name": "CVE-2007-1652"
      },
      "impact_statement": "CVE-2007-1652 is a vulnerability in JanRain's myOpenID hosted service, on the OpenID\nProvider side. It does not apply to Spring Security in any version.\n\nNo affected software product is on record. The CVE record carries vendor \"n/a\", product\n\"n/a\" and version \"n/a\"; NVD lists a single unversioned CPE, cpe:2.3:a:openid:openid:*,\nwith no version bounds; the GitHub advisory GHSA-3x88-xvgr-m6fg is unreviewed and lists\nno affected package in any ecosystem; OSV has no entry for any spring-security artifact\n(control: the same query returns 5 entries for spring-security-config and 31 for\nspring-security-core); and spring.io publishes no advisory for this CVE. Every one of the\neight references points to JanRain's myOpenID security-fix announcement of March 2007 or\nto the openid.net security mailing list threads of the same month, where the reporter\nstates the problem had to be fixed on the myOpenID server.\n\nThe reported mechanism is Provider-side by construction. A crafted web page uses a cached\nauthentication token and an existing Provider session to forcibly log a user into an\nOpenID-enabled site, release the user's personal information to it, and silently add that\nsite to the user's trusted-sites list. A trusted-sites auto-approval list exists only at\nan OpenID Provider; a relying party has no such list and no auto-approval step at which\nthe flaw could occur.\n\nThe openid module of Spring Security implements only the relying-party (consumer) role.\nOpenIDAuthenticationFilter drives the two-leg consumer flow and OpenID4JavaConsumer wraps\nopenid4java's ConsumerManager. The only openid4java packages referenced in the tree are\nconsumer, discovery, message and association - there is no use of org.openid4java.server,\nno ServerManager, no OpenID Provider implementation, and no trusted-sites or auto-approval\nhandling of any kind. No openid4java sources are vendored into the tree.\n\nNor could this library have been affected when the issue was disclosed: the CVE was\npublished on 24 March 2007, while the earliest OpenID code in the project dates from\n20 April 2007 and only reached the shipped openid module in January 2008.\n\nResolved consistently with spring-security 5.6.10 (VPV 9976), 5.7.11 (43741),\n5.7.12 (12031), 5.7.14 (40534) and 5.8.16 (330), all closed as false_positive."
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare",
          "identifiers": {
            "purl": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare"
          }
        }
      ],
      "timestamp": "2026-11-04T09:10:25.284357+00:00",
      "status_notes": "Vulnerability CVE-2023-34034 does not affect version 5.8.15.tuxcare of org.springframework.security:spring-security-config. CVE-2023-34034 (Spring Security WebFlux pattern matching bypass) is NOT present in this target. The vulnerability involved mismatched path pattern parsing between Spring Security and Spring WebFlux when using \"**\" wildcards, allowing authorization bypass. The fix (commit 7813a9ba26) is present in the target repository at Spring Security 5.8.15. This fix was authored by upstream maintainer Marcus Da Coregio and shipped in the upstream 5.8.15 release, which TuxCare onboarded without modification. All three components of the patch are verified present: (1) PathPatternParserServerWebExchangeMatcher calls initFullPathPattern() before parsing patterns, (2) AbstractServerWebExchangeMatcherRegistry normalizes patterns via parsePatterns(), and (3) ServerHttpSecurity retrieves PathPatternParser from RequestMappingHandlerMapping when available. The vulnerable pattern (missing initFullPathPattern normalization) does not exist in the target code.\n\nAdvisory cross-check (dlmn): outside the affected ranges of GitHub (>= 5.6.0, < 5.6.12; >= 5.7.0, < 5.7.10; >= 5.8.0, < 5.8.5; >= 6.0.0, < 6.0.5; >= 6.1.0, < 6.1.2), NVD (>= 5.6.0, < 5.6.12; >= 5.7.0, < 5.7.10; >= 5.8.0, < 5.8.5; >= 6.0.0, < 6.0.5; >= 6.1.0, < 6.1.2), cve.org (>= 6.1.0, <= 6.1.1; >= 6.0.0, <= 6.0.4; >= 5.8.0, <= 5.8.4; >= 5.7.0, <= 5.7.9; >= 5.6.0, <= 5.6.11), Snyk (>= 5.6.0, < 5.6.12; >= 5.7.0, < 5.7.10; >= 5.8.0, < 5.8.5; >= 6.0.0, < 6.0.5; >= 6.1.0, < 6.1.2).",
      "justification": "vulnerable_code_not_present",
      "vulnerability": {
        "name": "CVE-2023-34034"
      },
      "impact_statement": "CVE-2023-34034 (Spring Security WebFlux pattern matching bypass) is NOT present in this target. The vulnerability involved mismatched path pattern parsing between Spring Security and Spring WebFlux when using \"**\" wildcards, allowing authorization bypass. The fix (commit 7813a9ba26) is present in the target repository at Spring Security 5.8.15. This fix was authored by upstream maintainer Marcus Da Coregio and shipped in the upstream 5.8.15 release, which TuxCare onboarded without modification. All three components of the patch are verified present: (1) PathPatternParserServerWebExchangeMatcher calls initFullPathPattern() before parsing patterns, (2) AbstractServerWebExchangeMatcherRegistry normalizes patterns via parsePatterns(), and (3) ServerHttpSecurity retrieves PathPatternParser from RequestMappingHandlerMapping when available. The vulnerable pattern (missing initFullPathPattern normalization) does not exist in the target code.\n\nAdvisory cross-check (dlmn): outside the affected ranges of GitHub (>= 5.6.0, < 5.6.12; >= 5.7.0, < 5.7.10; >= 5.8.0, < 5.8.5; >= 6.0.0, < 6.0.5; >= 6.1.0, < 6.1.2), NVD (>= 5.6.0, < 5.6.12; >= 5.7.0, < 5.7.10; >= 5.8.0, < 5.8.5; >= 6.0.0, < 6.0.5; >= 6.1.0, < 6.1.2), cve.org (>= 6.1.0, <= 6.1.1; >= 6.0.0, <= 6.0.4; >= 5.8.0, <= 5.8.4; >= 5.7.0, <= 5.7.9; >= 5.6.0, <= 5.6.11), Snyk (>= 5.6.0, < 5.6.12; >= 5.7.0, < 5.7.10; >= 5.8.0, < 5.8.5; >= 6.0.0, < 6.0.5; >= 6.1.0, < 6.1.2)."
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare",
          "identifiers": {
            "purl": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare"
          }
        }
      ],
      "timestamp": "2026-11-04T09:15:51.446651+00:00",
      "status_notes": "Vulnerability CVE-2023-34035 does not affect version 5.8.15.tuxcare of org.springframework.security:spring-security-config. Spring Security 5.8.15 is NOT affected by CVE-2023-34035. The vulnerability involves authorization rule misconfiguration when using requestMatchers(String) with multiple servlets. The target contains a comprehensive runtime-deferred fix (commit 4ca54683ae \"Defer requestMatchers Validation to Runtime\") that was shipped by upstream Spring Security in version 5.8.15. This fix creates both MVC and Ant matchers at configuration time, then defers the decision to runtime using DeferredRequestMatcher and DispatcherServletDelegatingRequestMatcher. At request time, the code inspects which servlet is handling the request and selects the appropriate matcher type, preventing the vulnerability pattern where the wrong matcher type could cause authorization rules to be applied incorrectly. The fix was authored by Josh Cummings (josh.cummings@gmail.com) and was already present when TuxCare onboarded version 5.8.15 (first TuxCare commit: b44490807c \"Onboard version 5.8.15\").\n\nAdvisory cross-check (dlmn): outside the affected ranges of GitHub (>= 5.8.0, < 5.8.5; >= 6.0.0, < 6.0.5; >= 6.1.0, < 6.1.2), NVD (>= 5.8.0, < 5.8.5; >= 6.0.0, < 6.0.5; >= 6.1.0, < 6.1.2), cve.org (>= 5.8.0, <= 5.8.4; >= 6.0.0, <= 6.0.4; >= 6.1.0, <= 6.1.1), Snyk (>= 5.8.0, < 5.8.5; >= 6.0.0, < 6.0.5; >= 6.1.0, < 6.1.2).",
      "justification": "vulnerable_code_not_present",
      "vulnerability": {
        "name": "CVE-2023-34035"
      },
      "impact_statement": "Spring Security 5.8.15 is NOT affected by CVE-2023-34035. The vulnerability involves authorization rule misconfiguration when using requestMatchers(String) with multiple servlets. The target contains a comprehensive runtime-deferred fix (commit 4ca54683ae \"Defer requestMatchers Validation to Runtime\") that was shipped by upstream Spring Security in version 5.8.15. This fix creates both MVC and Ant matchers at configuration time, then defers the decision to runtime using DeferredRequestMatcher and DispatcherServletDelegatingRequestMatcher. At request time, the code inspects which servlet is handling the request and selects the appropriate matcher type, preventing the vulnerability pattern where the wrong matcher type could cause authorization rules to be applied incorrectly. The fix was authored by Josh Cummings (josh.cummings@gmail.com) and was already present when TuxCare onboarded version 5.8.15 (first TuxCare commit: b44490807c \"Onboard version 5.8.15\").\n\nAdvisory cross-check (dlmn): outside the affected ranges of GitHub (>= 5.8.0, < 5.8.5; >= 6.0.0, < 6.0.5; >= 6.1.0, < 6.1.2), NVD (>= 5.8.0, < 5.8.5; >= 6.0.0, < 6.0.5; >= 6.1.0, < 6.1.2), cve.org (>= 5.8.0, <= 5.8.4; >= 6.0.0, <= 6.0.4; >= 6.1.0, <= 6.1.1), Snyk (>= 5.8.0, < 5.8.5; >= 6.0.0, < 6.0.5; >= 6.1.0, < 6.1.2)."
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare",
          "identifiers": {
            "purl": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare"
          }
        }
      ],
      "timestamp": "2026-09-24T09:31:26.931840+00:00",
      "status_notes": "Vulnerability CVE-2023-34042 does not affect version 5.8.15.tuxcare of org.springframework.security:spring-security-config. not_affected \u2014 CVE-2023-34042 affects Spring Security versions 5.8.4-5.8.6 due to a world-writable symlink at config/src/main/resources/org/springframework/security/config/spring-security.xsd. The target version 5.8.15.tuxcare.1 is not affected because the upstream vendor fix (commit 5b293d21161e946bf241d9e974b9af93cfafaaac by Rob Winch) was included in upstream version 5.8.7 and inherited by this version. Th...",
      "justification": "vulnerable_code_not_present",
      "vulnerability": {
        "name": "CVE-2023-34042"
      },
      "impact_statement": "not_affected \u2014 CVE-2023-34042 affects Spring Security versions 5.8.4-5.8.6 due to a world-writable symlink at config/src/main/resources/org/springframework/security/config/spring-security.xsd. The target version 5.8.15.tuxcare.1 is not affected because the upstream vendor fix (commit 5b293d21161e946bf241d9e974b9af93cfafaaac by Rob Winch) was included in upstream version 5.8.7 and inherited by this version. Th..."
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare",
          "identifiers": {
            "purl": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare"
          }
        }
      ],
      "timestamp": "2026-10-29T02:11:01.060172+00:00",
      "status_notes": "Vulnerability CVE-2025-22223 does not affect version 5.8.15.tuxcare of org.springframework.security:spring-security-config. not_affected \u2014 Version 5.8.15 is not affected by CVE-2025-22223. The vulnerability exists in the UniqueSecurityAnnotationScanner class introduced in Spring Security 6.4, which uses getDeclaredMethod() with raw parameter types that fail to match methods with resolved generic types. Version 5.8.15 predates this architecture and uses a different annotation scanning mechanism (AuthorizationAnnotationUtils + Sprin...",
      "justification": "vulnerable_code_not_present",
      "vulnerability": {
        "name": "CVE-2025-22223"
      },
      "impact_statement": "not_affected \u2014 Version 5.8.15 is not affected by CVE-2025-22223. The vulnerability exists in the UniqueSecurityAnnotationScanner class introduced in Spring Security 6.4, which uses getDeclaredMethod() with raw parameter types that fail to match methods with resolved generic types. Version 5.8.15 predates this architecture and uses a different annotation scanning mechanism (AuthorizationAnnotationUtils + Sprin..."
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare",
          "identifiers": {
            "purl": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare"
          }
        }
      ],
      "timestamp": "2026-09-24T09:31:26.931840+00:00",
      "status_notes": "Vulnerability CVE-2026-22753 does not affect version 5.8.15.tuxcare of org.springframework.security:spring-security-config. Spring Security 5.8.15 is not affected by CVE-2026-22753. The vulnerability exists in versions 7.0.0-7.0.4 which use the PathPatternRequestMatcher architecture introduced in Spring Security 7.0. Version 5.8.15 uses a completely different request matching architecture (MvcRequestMatcher/AntPathRequestMatcher) that predates PathPatternRequestMatcher. The vulnerable code pattern\u2014specifically the PathPatternRequestMatcher.Builder bean mechanism and the builder pattern bug in PathPatternRequestMatcherFactoryBean\u2014does not exist in this version.",
      "justification": "vulnerable_code_not_present",
      "vulnerability": {
        "name": "CVE-2026-22753"
      },
      "impact_statement": "Spring Security 5.8.15 is not affected by CVE-2026-22753. The vulnerability exists in versions 7.0.0-7.0.4 which use the PathPatternRequestMatcher architecture introduced in Spring Security 7.0. Version 5.8.15 uses a completely different request matching architecture (MvcRequestMatcher/AntPathRequestMatcher) that predates PathPatternRequestMatcher. The vulnerable code pattern\u2014specifically the PathPatternRequestMatcher.Builder bean mechanism and the builder pattern bug in PathPatternRequestMatcherFactoryBean\u2014does not exist in this version."
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare",
          "identifiers": {
            "purl": "pkg:maven/org.springframework.security/spring-security-config@5.8.15.tuxcare"
          }
        }
      ],
      "timestamp": "2026-09-24T09:31:26.931840+00:00",
      "status_notes": "Vulnerability CVE-2026-22754 does not affect version 5.8.15.tuxcare of org.springframework.security:spring-security-config. Spring Security 5.8.15 is not affected by CVE-2026-22754. The vulnerable code class PathPatternRequestMatcherFactoryBean introduced in version 7.0.x does not exist in 5.8.15. This version uses MvcRequestMatcher with correctly implemented servlet path handling through bean properties and a properly functioning builder pattern. The specific bug (failing to capture builder.basePath() return value) is not present in any code path.",
      "justification": "vulnerable_code_not_present",
      "vulnerability": {
        "name": "CVE-2026-22754"
      },
      "impact_statement": "Spring Security 5.8.15 is not affected by CVE-2026-22754. The vulnerable code class PathPatternRequestMatcherFactoryBean introduced in version 7.0.x does not exist in 5.8.15. This version uses MvcRequestMatcher with correctly implemented servlet path handling through bean properties and a properly functioning builder pattern. The specific bug (failing to capture builder.basePath() return value) is not present in any code path."
    }
  ]
}