Unvalidated OData __next URLs can expose authentication data in SAP pyodata

A malicious or compromised OData service could disclose sensitive authentication information and inject untrusted data into the application, which may leads to a high impact on confidentiality and low impact on integrity and no impact on Availability.

• SAP Odata, pyodata package from pip: affected at pyodata (pip) < 1.11.2 according to the CNA record.
• The GitHub advisory identifies 1.12.0 as a patched version and instructs users to upgrade to 1.12.0 or later.
• The CNA record lists no other product, package, or deployment branch. Because the CNA affected boundary and the advisory's patched-version statement are not identical, deployments using an intermediate branch should be checked against vendor release guidance rather than inferred from another branch.

The affected component is pyodata handling of OData __next URLs. The advisory attributes the flaw to insufficient validation of externally supplied __next URLs, allowing a malicious or compromised OData service to cause subsequent requests to be redirected to unintended destinations.

At a high level, the sequence is:

• An application uses pyodata to query an OData service.
• The OData service supplies an externally controlled __next value.
• pyodata processes the value without adequately validating the destination, causing a request redirect.
• Sensitive authentication information may be disclosed and untrusted data may be injected into the application.

The record describes network reachability, low privileges required, high attack complexity, and no user interaction. The exact request sequence, authentication material affected, and specific caller contexts have not been documented.

Exploitation requires an application to use pyodata with a malicious or compromised OData service. The record describes network reachability, low privileges required, high attack complexity, and no user interaction.

The CISA enrichment records exploitation as none and automation as no at the time of its assessment. The supplied record also does not record a public exploit, named exploit, campaign, or victim. This does not establish that every deployment is safe, because exposure depends on which OData services the application trusts and how it handles subsequent requests.

The flaw allows an OData service-supplied __next value to influence the destination of subsequent requests. The technical outcome may include disclosure of sensitive authentication information and injection of untrusted data into the application.

The recorded impact is high for confidentiality, low for integrity, and none for availability. The current assessment does not describe a change in security scope beyond the affected component. Organizational harm depends on the privileges of any exposed credential, the data processed by the application, and whether the OData service can control the redirect value; these details have not been fully disclosed.

• Sensitive authentication information may be disclosed when the application sends subsequent requests to an unintended destination.
• Untrusted data may enter the application, creating a risk to data integrity or business processing.
• The practical consequence depends on the type of authentication material sent, the privileges associated with it, and the data the application accepts from the OData service.
• The record describes high confidentiality impact, low integrity impact, and no availability impact. The available evidence does not identify a specific breach or confirmed compromise.

1. Check the deployment inventory and upgrade pyodata to 1.12.0, which the advisory identifies as patched. The advisory also instructs users to upgrade to 1.12.0 or later.
2. Verify the actual package version in every runtime, image, virtual environment, and lockfile after the upgrade.
3. Review applications that use OData services outside organizational control and prioritize those that send authentication information in subsequent requests.
4. If an upgrade cannot be completed, the advisory provides no workaround. Obtain guidance from SAP or the maintainer and assess, under the organization's deployment policy, whether access to untrusted OData services can be restricted temporarily.
5. After remediation, review outbound logs and request destinations derived from __next for unexpected redirects.

• Inventory application dependencies and identify environments running pyodata within the affected range.
• Check the exact package version from lockfiles, manifests, Python environment metadata, or package-management tooling rather than relying only on the version of a wrapping application.
• Identify applications that use external OData services or services not fully controlled by the organization.
• Review OData client and outbound HTTP logs for __next processing that leads to an unexpected destination, especially when the destination differs from the configured OData host. This is a precautionary check based on the vulnerability mechanism, not a vendor-confirmed IOC.
• Check whether authentication information is sent or processed in subsequent requests after an application receives a __next URL.

No specific log signature or IOC has been published. The absence of redirect evidence does not prove that an environment is unaffected.