Skip to content
eastbaycyber

CVE-2026-15704: Authorization Bypass in Eclipse BaSyx Go Components

CVE explainers 10 min read
SR
Security Research Desk Expert reviewed
Threat intelligence · Human-verified · Updated 2026-07-24
▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.
CISOBrief · 30-second brief

TL;DR - Critical auth bypass in ABAC-enabled Eclipse BaSyx Go Components up to and including 1.0.0. - Appending a trailing slash can evade intended ABAC checks on protected routes. - Upgrade to 1.0.1 immediately; no confirmed in-the-wild exploitation is publicly reported.

Vulnerability at a Glance

Field Value
CVE ID CVE-2026-15704
CVSS score 9.8 (Critical)
Attack vector Network
Auth required None for exploitation path as described; impact depends on exposed route and policy
Patch available Yes
Fixed version 1.0.1
Affected versions Up to and including 1.0.0
Exposure condition ABAC-enabled deployments using the shared router and ABAC middleware

This is a classic normalization mismatch issue with a serious access-control outcome. In vulnerable deployments, the authorization layer and the HTTP router do not agree on the effective request path. That discrepancy allows requests with a trailing slash to reach handlers that should have been subject to ABAC policy enforcement.

From a defender’s perspective, the most important detail is scope. This is not a generic bug affecting every BaSyx deployment equally. The issue specifically applies to ABAC-enabled deployments of Eclipse BaSyx Go Components that use the vulnerable shared router and middleware behavior. If your environment matches that description and you expose those APIs over the network, treat this as urgent.

What Is This Vulnerability?

CVE-2026-15704 is an authorization bypass caused by inconsistent handling of trailing slashes between the ABAC middleware and the router stack. According to the published description, the shared router configuration used Chi’s middleware.StripSlashes, which means a request such as /shells/ could be normalized and dispatched to the registered /shells route.

The problem is that the ABAC middleware evaluated the original request path, including the trailing slash. If policy lookup expected /shells but received /shells/, the authorization layer might fail to match the route as intended. In the vulnerable flow, the request could continue onward without the expected authorization decision or ABAC query filtering, after which the router normalized the path and executed the protected handler anyway.

In practical terms, this creates a bypass condition where a remote attacker can try slash-suffixed variants of protected endpoints. If the authorization layer misses the route but the router still resolves it after normalization, the attacker may gain access to operations that should have been denied.

This type of bug matters because it breaks a basic security assumption: the component making the access-control decision must evaluate the exact same resource identity that the application ultimately serves. When those representations differ, policy gaps emerge. In this case, the mismatch is simple enough that exploitation may be straightforward in exposed ABAC-enabled environments.

Technical Notes

The vulnerable pattern described in the advisory is conceptually similar to:

Protected route registered as: GET /shells
Attacker sends:              GET /shells/
ABAC checks:                 /shells/
Router executes:             /shells
Outcome:                     handler may run without intended ABAC enforcement

The router behavior specifically referenced in the public description involves Chi slash normalization:

r.Use(middleware.StripSlashes)

If your security middleware authorizes the raw path while your router canonicalizes it before dispatch, you should review the entire request pipeline for equivalent mismatches.

AnalystImpact · assess the risk

Who Is Affected?

The confirmed affected product is Eclipse BaSyx Go Components. The confirmed affected version range is up to and including 1.0.0. The fixed version is 1.0.1. Those are the version boundaries defenders should use for immediate scoping and remediation planning.

The deployment condition is equally important: the issue affects ABAC-enabled deployments of services using the shared router and ABAC middleware. The NVD text states that affected services include ABAC-enabled deployments using that shared pattern, and it references AAS-related components, though the publicly quoted NVD snippet available here is truncated. Because of that truncation, defenders should avoid assuming either broader or narrower component scope than what they can verify in their own environment.

If you run BaSyx Go Components at version 1.0.0 or earlier and you have ABAC enabled, you should assume exposure until proven otherwise. If ABAC is not enabled, the specific bypass path described here may not apply, but you should still validate your deployment architecture rather than relying on assumption alone.

For asset owners, the fastest way to determine likely exposure is to answer three questions:

  1. Are you running Eclipse BaSyx Go Components version 1.0.0 or earlier?
  2. Is ABAC enabled in the affected service?
  3. Is the service reachable by untrusted or semi-trusted network clients?

If the answer to all three is yes, prioritize patching and verification.

Technical Notes

Example version-checking approaches will vary by deployment method. If you built or pulled a tagged release, verify the deployed artifact against the fixed release:

# Example: inspect container image tags in your deployment manifests
grep -R "basyx-go-components" ./deploy ./manifests ./helm 2>/dev/null

# Example: if using Git tags in a checked-out source deployment
git describe --tags

You are looking to identify whether the deployed version is 1.0.0 or earlier and whether an upgrade to 1.0.1 has not yet been applied.

CVSS Score Breakdown

The published CVSS score is 9.8, which places this issue in the Critical range. The NVD output available in the research note did not include the full vector string, so defenders should avoid citing unverified sub-metrics beyond what the score reliably implies. A 9.8 rating strongly aligns with a remotely reachable vulnerability that is low complexity, requires no prior privileges, and can materially impact confidentiality, integrity, and availability depending on deployment context.

That severity makes sense for an authorization bypass on exposed API routes. If an unauthenticated attacker can reach API handlers that are expected to be protected by ABAC, the security boundary around sensitive object retrieval, creation, modification, deletion, or upload actions may fail. In industrial and digital-twin contexts, that can translate into direct business risk, including unauthorized asset data access and tampering.

It is also worth noting that CVSS alone does not capture deployment nuance. In this case, actual exploitability depends on whether ABAC is enabled, which routes are exposed, which methods are allowed, and how policies are configured. A critical score should drive urgency, but your incident and patch priority should also consider external exposure, compensating controls, and business sensitivity of the protected data and functions.

Because the full vector was not available in the provided source material, defenders should assume the high score reflects a worst-case remote exploitation profile and respond accordingly rather than waiting for more detailed scoring metadata.

Exploitation Status

As of the date provided, there is no CISA-confirmed evidence of active exploitation in the wild. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. That means organizations should not describe it as KEV-listed or actively exploited unless they have separate evidence from their own telemetry or trusted threat intelligence.

There is also no confirmed public proof-of-concept (PoC) in the source material provided. That said, the vulnerability description is detailed enough that a PoC would likely be straightforward for a researcher or attacker with access to a vulnerable ABAC-enabled deployment. The attack pattern is simple: identify a protected route, append a trailing slash, and compare behavior with and without the slash.

So the most accurate current phrasing is:

  • Public PoC: none confirmed from the provided sources
  • Active exploitation in the wild: none confirmed from the provided sources
  • Defender assumption: exploitation is plausible and should be treated as practical due to the simplicity of the bypass condition

In short, lack of public exploitation evidence should not be mistaken for low risk. This is the kind of bug that can be exercised quickly once an exposed target is found.

ResponderRunbook · act now

How to Detect It

Detection should focus on inconsistencies between expected authorization outcomes and actual routed requests. Start by reviewing HTTP access logs, reverse proxy logs, and any application-level audit logs for requests to protected endpoints that include a trailing slash where your normal API patterns do not. Pay close attention to successful GET, POST, PUT, PATCH, DELETE, or upload-related requests that should have triggered policy checks.

You should also test your own deployment behavior directly. For each protected endpoint, send requests with and without a trailing slash and compare status codes, response bodies, and audit entries. If /resource is denied or filtered by ABAC but /resource/ succeeds or returns unexpectedly broad data, treat that as a strong indicator of exposure.

Because the exact log schema varies by deployment, defenders should look for three classes of evidence:

  1. Requests to slash-suffixed protected endpoints.
  2. Successful responses on routes that should have been denied by ABAC.
  3. Mismatches between the logged raw request path and the handler route ultimately executed.

Technical Notes

Example suspicious path patterns:

GET /shells/
POST /shells/
PUT /submodels/
DELETE /assets/

Basic grep-style hunting in access logs:

grep -E '"(GET|POST|PUT|PATCH|DELETE) [^"]+/" [23][0-9]{2} ' /var/log/nginx/access.log

If logs include policy or authz decisions, compare slash and non-slash variants:

grep -E '(/shells/?|/submodels/?|/assets/?)' /var/log/app/*.log

Example Splunk-style query for successful slash-suffixed API requests:

index=app_logs ("GET" OR "POST" OR "PUT" OR "PATCH" OR "DELETE")
| regex uri_path=".+/$"
| search status>=200 status<300
| stats count by host, method, uri_path, status

Example Sigma-like logic concept:

title: Successful requests to API paths with trailing slash
logsource:
  product: webserver
detection:
  selection:
    cs-method:
      - GET
      - POST
      - PUT
      - PATCH
      - DELETE
  path:
    cs-uri-stem|endswith: '/'  
  condition: selection and path
level: medium

If you do not currently log raw request paths before normalization, consider that a visibility gap. Add logging at the reverse proxy or middleware layer so you can distinguish /route from /route/.

Mitigation and Patching

The primary remediation is to upgrade Eclipse BaSyx Go Components to version 1.0.1 or later. The fix is explicitly tied to release v1.0.1, and that is the version defenders should target. If you are on 1.0.0 or earlier in an ABAC-enabled deployment, upgrading should be the default action.

After patching, validate the fix rather than assuming it is effective. Re-test representative protected endpoints with both normalized and slash-suffixed forms. Confirm that authorization behavior is consistent, that denied requests remain denied regardless of trailing slash usage, and that ABAC query filters still apply where expected.

If you cannot patch immediately, implement compensating controls at the edge. The safest interim option is to normalize or reject trailing-slash variants of sensitive API paths before requests reach the vulnerable middleware/router combination. Whether that means redirecting, rewriting, or explicitly denying slash-suffixed protected routes depends on your API compatibility requirements, but consistency is the goal.

Also review any custom middleware, ingress rules, or reverse proxy rewrites. If different layers canonicalize paths differently, you may still have authz discrepancies even after applying this specific fix.

Technical Notes

Upgrade to the fixed release in source-based deployments:

git fetch --tags
git checkout v1.0.1

If your build pipeline compiles from source, rebuild and redeploy from the v1.0.1 tag:

git fetch --tags
git checkout v1.0.1
go build ./...

If you use containers, update image tags in manifests to the vendor/project release corresponding to 1.0.1 and redeploy. Verify your own image naming conventions rather than guessing tag names.

As an interim reverse-proxy workaround, you can reject slash-suffixed API paths. Example NGINX concept:

location ~ ^/(shells|submodels|assets)/+$ {
    return 403;
}

Or normalize consistently before upstream handling:

rewrite ^(.+)/+$ $1 permanent;

Use care with rewrites on APIs, as redirects may affect clients. If you cannot safely redirect, explicit denial of slash-suffixed protected endpoints may be preferable until the application is patched.

Post-patch verification test:

curl -i https://example.local/shells
curl -i https://example.local/shells/

The authorization outcome should be consistent with policy, not altered by the presence of a trailing slash.

References

The most authoritative public references for this issue are the NVD entry and the project release and fix references. These establish the affected product, impacted version range, root cause summary, and fixed version. Defenders should use them as the baseline for internal remediation records and change management.

Because some public summaries are truncated, teams should cross-check the release notes and fix pull request when doing impact analysis. That helps confirm which deployed services use the shared router and ABAC middleware pattern in your environment.

In the absence of confirmed public PoC or active exploitation reporting, defenders should still treat this as a high-priority patch because it undermines authorization enforcement on network-accessible APIs. For most organizations, the right next step is simple: identify ABAC-enabled BaSyx Go deployments on 1.0.0 or earlier, upgrade to 1.0.1, and test slash-variant requests as part of post-fix validation.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Last verified: 2026-07-24

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.