الوصف الكامل

Prior to 2025-11-03, well-intended users of Terraform or REST API for Google Cloud AlloyDB for PostgreSQL could have created clusters with an insecure default password which could have been exploited by a remote attacker to gain full administrative access to the database. Exploitation required network access to the AlloyDB cluster and was limited to Terraform or the REST API, as other clients blocked it.

نوع الثغرة

CWE-1392 — CWE-1392

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber

المراجع

الوصف الكامل

Open edX Platform enables the authoring and delivery of online learning at any scale. The sync_provider_data endpoint in SAMLProviderDataViewSet allows authenticated Enterprise Admin users to supply an arbitrary URL via the metadata_url POST parameter. This URL is passed directly to requests.get() in fetch_metadata_xml() without any URL validation, IP filtering, or scheme enforcement. An attacker with Enterprise Admin privileges can force the server to make HTTP requests to internal network services, cloud metadata endpoints (e.g., AWS 169.254.169.254), or other attacker-controlled destinations. This vulnerability is fixed by commit 6fda1f120ff5a590d120ae1180185525f399c6d0 and 70a56246dd9c9df57c596e64bdd8a11b1d9da054.

نوع الثغرة

CWE-918 — SSRF

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

المراجع

الوصف الكامل

kafka-sink-azure-kusto Kafka Connect plugin is the official Microsoft sink for Azure Data Explorer (Kusto). Prior to 5.2.3, kafka-sink-azure-kusto did not sanitize user-controlled values inside the kusto.tables.topics.mapping configuration. The db, table, mapping, and format fields of each mapping entry were interpolated directly into KQL management/query commands via String.formatted(...) (e.g., FETCH_TABLE_COMMAND.formatted(table) → "<table> | count", FETCH_TABLE_MAPPING_COMMAND.formatted(table, format, mapping) → ".show table <table> ingestion <format> mapping '<mapping>'"). An actor able to influence the connector configuration (for example, someone with permissions to submit or edit Kafka Connect connector configs) could embed KQL metacharacters (;, |, ') to execute arbitrary management commands in the context of the connector's service principal — enabling schema enumeration/modification, ingestion-mapping tampering, or changes to streaming/retention policies on the target Azure Data Explorer database. This is a tampering vulnerability. Exploitation requires privileged access to the connector configuration; no end-user interaction or Kafka record payload is involved. This vulnerability is fixed in 5.2.3.

نوع الثغرة

CWE-943 — NoSQL Injection

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N

المراجع

الوصف الكامل

Grav is a file-based Web platform. Prior to 2.0.0-rc.2, the Twig sandbox allow-list permits any user with the admin.pages role to call config.toArray() from within a page body, dumping the entire merged site configuration — including all plugin secrets (SMTP passwords, AWS keys, OAuth client secrets, API tokens) — into the rendered HTML. No administrator privileges are required. This vulnerability is fixed in 2.0.0-rc.2.

نوع الثغرة

CWE-200 — Info Disclosure

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

المراجع

الوصف الكامل

Plunk is an open-source email platform built on top of AWS SES. Prior to version 0.9.0, the /webhooks/sns endpoint accepts Amazon SNS notification payloads from unauthenticated requests without verifying the SNS signature, certificate, or topic ARN, meaning anyone can forge a valid-looking webhook request. This allows an unauthenticated attacker to spoof SNS events to trigger workflow automations, unsubscribe contacts, manipulate email delivery metrics, and potentially exhaust billing credits. This issue has been patched in version 0.9.0.

نوع الثغرة

CWE-347 — CWE-347

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

المراجع

الوصف الكامل

Plunk is an open-source email platform built on top of AWS SES. Prior to version 0.9.0, a stored cross-site scripting (XSS) vulnerability exists in the campaign management feature, where the email body content created by authenticated project members is stored and later rendered in the admin dashboard using React's dangerouslySetInnerHTML without any HTML sanitization. This allows a lower-privileged member to embed malicious scripts in a campaign's email body that execute in the context of any admin or other member who views the campaign, potentially enabling session hijacking or unauthorized actions on their behalf. This issue has been patched in version 0.9.0.

نوع الثغرة

CWE-79 — XSS

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

المراجع

الوصف الكامل

In OpenStack Ironic before 35.0.2 (in a certain non-default configuration), instance_info['ks_template'] is rendered without sandboxing.

نوع الثغرة

CWE-1336 — CWE-1336

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:N

المراجع

الوصف الكامل

Exposure of sensitive information to an unauthorized actor in Azure DevOps allows an unauthorized attacker to disclose information over a network.

نوع الثغرة

CWE-200 — Info Disclosure

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

المراجع

الوصف الكامل

Server-side request forgery (ssrf) in Azure Notification Service allows an authorized attacker to elevate privileges over a network.

نوع الثغرة

CWE-918 — SSRF

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

المراجع

الوصف الكامل

In OpenStack Cyborg before 16.0.1, the Accelerator Request (ARQ) API does not enforce project ownership at any layer. The project_id column in the database is never populated (NULL for every ARQ), database queries have no project filtering, and policy checks are self-referential (the authorize_wsgi decorator compares the caller's project_id with itself rather than the target resource). Any authenticated non-admin user can complete various actions such as deleting ARQs bound to other projects' instances, aka cross-tenant denial of service.

نوع الثغرة

CWE-282 — CWE-282

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L

المراجع

الوصف الكامل

OpenStack Cyborg before 16.0.1 uses rule:allow (check_str='@') as the default policy for multiple API endpoints. This unconditionally authorizes any request carrying a valid Keystone token regardless of roles, project membership, or scope. An authenticated user with zero role assignments can complete various actions such as reprogramming FPGA bitstreams on arbitrary compute nodes via agent RPC.

نوع الثغرة

CWE-863 — Incorrect Authorization

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L

المراجع

الوصف الكامل

Improper access control in Azure AI Foundry M365 published agents allows an unauthorized attacker to elevate privileges over a network.

نوع الثغرة

CWE-284 — CWE-284

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

المراجع

الوصف الكامل

Improper neutralization of special elements used in a command ('command injection') in Azure Cloud Shell allows an unauthorized attacker to perform spoofing over a network.

نوع الثغرة

CWE-77 — Command Injection

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

المراجع

الوصف الكامل

Improper neutralization of input during web page generation ('cross-site scripting') in Azure Machine Learning allows an unauthorized attacker to perform spoofing over a network.

نوع الثغرة

CWE-79 — XSS

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

# Summary When the Vercel CLI runs in non-interactive mode (`--non-interactive` or auto-detected AI agent), commands that cannot complete autonomously emit JSON payloads with suggested follow-up commands. If the user authenticated via `--token` or `-t` on the command line, the token value is included verbatim in those suggestions. # Conditions All three must be true for the token to appear in output: 1. Token passed as a CLI argument (`--token` / `-t`). The `VERCEL_TOKEN` environment variable is **not affected**. 2. Non-interactive mode is active (explicit flag or AI agent auto-detection). 3. The command cannot complete on its own (e.g. missing `--yes`, ambiguous scope, API errors). Successful commands produce no suggestion output. ## Impact The plaintext token may be captured in CI/CD logs, agent transcripts, or other automation output. ## Remediation - Upgrade to the patched version. - If developers have previously used `--token` with `--non-interactive` in their applications, review logs for exposed tokens and rotate them. - Prefer `VERCEL_TOKEN` environment variable for authentication.

الإصدارات المتأثرة

50.16.0 → 52.0.1

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N

المراجع

الوصف الكامل

### Summary A server-side authentication bypass in `azureauthextension` allows any party who holds a single valid Azure access token for *any scope the collector's configured identity can mint for* to authenticate to any OpenTelemetry receiver that uses `auth: azure_auth`. The extension's `Authenticate` method does not validate incoming bearer tokens as JWTs. Instead, it calls its own configured credential to obtain an access token and compares the client's token to the result with string equality — and the scope for that server-side token request is taken from the client-supplied `Host` header. As a result, a token minted for any Azure resource the service principal has ever been issued a token for (ARM, Graph, Key Vault, Storage, etc.) will authenticate to the collector if the attacker picks a matching `Host`. Tokens are replayable for the full issued lifetime (commonly several hours for managed identity tokens). Severity: High (CVSS 8.1). See "Threat model" below for the preconditions that inform that score. ### Root cause The extension implements both `extensionauth.HTTPClient` (outbound: "attach my identity to requests I send") and `extensionauth.Server` (inbound: "validate a credential someone presented to me"). Those two interfaces look symmetric but are not: holding a credential to present says nothing about the ability to validate a credential someone else presents. The outbound path only requires `credential.GetToken()`; the inbound path requires JWT signature verification against the issuer's JWKS, issuer/audience/exp/nbf checks, and an algorithm allowlist — none of which the extension does. PR #39178 ("Implement extensionauth.HTTPClient and extensionauth.Server interface functions") added the `Server` path in v0.124.0 by reusing the same credential object and comparing strings. That server-side path is present in every release through v0.150.0. The outbound `HTTPClient` path (used by Azure exporters) is unaffected. ### Details Vulnerable code — `extension/azureauthextension/extension.go:208–235`: ```go func (a *authenticator) Authenticate(ctx context.Context, headers map[string][]string) (context.Context, error) { auth, err := getHeaderValue("Authorization", headers) if err != nil { return ctx, err } host, err := getHeaderValue("Host", headers) if err != nil { return ctx, err } authFormat := strings.Split(auth, " ") if len(authFormat) != 2 { /* ... */ } if authFormat[0] != "Bearer" { /* ... */ } token, err := a.getTokenForHost(ctx, host) // asks the collector's own identity if err != nil { return ctx, err } if authFormat[1] != token { // string comparison, not JWT validation return ctx, errors.New("unauthorized: invalid token") } return ctx, nil } ``` And `getTokenForHost` at `extension.go:187–206`: ```go options := policy.TokenRequestOptions{ Scopes: []string{ fmt.Sprintf("https://%s/.default", host), // client-supplied Host chooses scope }, } ``` Two independent problems compose here: **1. No JWT validation.** Real Entra ID bearer validation requires verifying the JWT signature against the tenant JWKS and checking `iss`, `aud`, `exp`, `nbf`, plus an algorithm allowlist. The extension does none of this. The "expected" value is a token the server mints from its own credential, not a signature to verify. Any party that already holds a valid token for the collector's identity — a co-tenant pod that shares the managed identity, any peer authenticated with the same service principal, any component that retained an `Authorization:` header — can replay it directly. **2. Attacker-controlled audience.** The scope used to mint the "expected" token comes from the client-supplied `Host` header: `https://<Host>/.default`. The `azcore` credential returns a consistent token per (identity, scope) pair within the cache window, so an attacker can pick any scope the SP has been issued a token for and match it by setting `Host` accordingly. This is the sharper of the two flaws: it means a token leaked from an unrelated Azure integration — ARM, Graph, Key Vault, a different Storage account — authenticates to the collector. The correct primitive is a real JWT validator — e.g. `github.com/coreos/go-oidc/v3` pointed at the tenant's discovery endpoint, with audience and issuer pinned *server-side from configuration*, never derived from request headers. ### Proof of concept Both variants assume a collector running with `azureauthextension` v0.124.0–v0.150.0, configured with any credential mode and referenced from a receiver's `auth:` block: ```yaml extensions: azure_auth: managed_identity: client_id: ${CLIENT_ID} receivers: otlp: protocols: http: endpoint: 0.0.0.0:4318 auth: authenticator: azure_auth service: extensions: [azure_auth] pipelines: traces: receivers: [otlp] exporters: [debug] ``` #### Variant A — Replay (same scope) The attacker controls a workload that shares the collector's managed identity (common in AKS when multiple pods bind the same UAMI). Both workloads query IMDS for `https://management.azure.com/.default` and receive the same cached token. The attacker replays: ``` POST /v1/traces HTTP/1.1 Host: management.azure.com Authorization: Bearer eyJ... # token minted for management.azure.com Content-Type: application/json {"resourceSpans":[...]} ``` `Authenticate` calls `getTokenForHost(ctx, "management.azure.com")`, receives the identical cached token, and the string comparison passes. #### Variant B — Scope confusion (the stronger case) The attacker holds a token for the SP issued for a *different* Azure resource — say Key Vault, obtained from an entirely unrelated integration. The collector was never intended to accept Key Vault tokens. The attacker sets `Host` to match: ``` POST /v1/traces HTTP/1.1 Host: vault.azure.net Authorization: Bearer eyJ... # token minted for vault.azure.net Content-Type: application/json {"resourceSpans":[...]} ``` `Authenticate` calls `getTokenForHost(ctx, "vault.azure.net")`. The collector's credential mints (or returns cached) a token for `https://vault.azure.net/.default` — the same token the attacker holds, because both come from the same SP issued for the same scope by the same IdP. Comparison passes. The collector accepts telemetry gated on "proof of identity to Key Vault." In a correct implementation, the JWT's `aud` would be pinned server-side to a value unrelated to `Host`, and Variant B would fail regardless of what the attacker put in the `Host` header. A small Go reproducer can be built around the extension's own test harness: the existing `TestAuthenticate` in `extension_test.go` is effectively a demonstration of the broken behavior — it passes when the client-supplied token equals the server-side token for the given `Host`, which is exactly what an attacker arranges. ### Impact **Vulnerability class:** Improper Authentication (CWE-287), with contributing CWE-347 (Improper Verification of Cryptographic Signature — no JWT validation), CWE-294 (Authentication Bypass by Capture-replay — tokens replayable for full TTL), and CWE-290 (Authentication Bypass by Spoofing — client `Host` header chooses the expected scope). **Threat model / precondition.** The attacker needs to already hold (or be able to obtain) a valid Azure access token issued to the collector's SP for any scope. In practice this is satisfied by: (a) controlling another workload that binds the same managed identity, (b) compromising any peer authenticated with the same SP, or (c) observing an `Authorization:` header from any prior legitimate request for the SP. This is what drives the 8.1 score — the precondition is non-trivial but is routine in multi-workload Azure environments. **Who is impacted.** Any operator of `opentelemetry-collector-contrib` v0.124.0 through v0.150.0 who configured `azureauthextension` on a receiver's `auth:` block. This applies to both HTTP and gRPC receivers — gRPC receivers surface `:authority` as `Host` through the collector's header handling, so the same exploit path applies there. **Deployments most at risk:** - Multi-workload Azure environments where the collector shares a managed identity with other workloads (any such workload can authenticate as an arbitrary telemetry source). - Deployments that forward `Authorization:` headers through proxies, service meshes, or logging pipelines (one leaked token is enough, and persists for the token TTL — typically several hours for MI tokens, not the 60-minute user-token window). - Multi-tenant environments where different customers' telemetry converges at a collector protected by this extension. **Consequences.** Unauthenticated (from the collector's perspective) ingest of arbitrary traces, metrics, and logs. Downstream effects depend on the collector's exporters and include telemetry-backend poisoning, log injection (masking real attacker activity in SIEMs), metric manipulation to trigger or suppress alerts, cost-amplification against pay-per-datapoint backends, and adversarial traces that corrupt service-graph and incident-triage signals. **Not impacted.** The extension's outbound `extensionauth.HTTPClient` path, used by Azure exporters, is unaffected. Operators who use `azureauthextension` only on exporters can continue doing so. ### Mitigation Until a patched release is available, remove `azure_auth` from any receiver `auth:` blocks. For genuine Entra ID JWT validation on OTLP receivers, use `oidcauthextension` pointed at the tenant discovery URL, with audience pinned from configuration: ```yaml extensions: oidc: issuer_url: https://login.microsoftonline.com/<tenant-id>/v2.0 audience: <expected-api-audience> ``` ### Resources - PR introducing the vulnerable server-side path: [#39178](https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/39178) - Affected versions: v0.124.0 – v0.150.0 Assisted-by: Opus 4.7

الإصدارات المتأثرة

All versions < 0.124.0

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

المراجع

الوصف الكامل

An issue was discovered in idrac in OpenStack Ironic before 35.0.1. During import, a user invoking molds can request authorization to be sent to a remote endpoint. The credential forwarded is a time-limited Keystone token (which provides access to all OpenStack services Ironic is authorized for); or basic credentials configured for molds storage. The fixed versions are 26.1.6, 29.0.5, 32.0.1, and 35.0.1.

الإصدارات المتأثرة

33.0.0 - 35.0.1

نوع الثغرة

CWE-669 — CWE-669

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

المراجع

الوصف الكامل

## Background The original concern is functional: a resource pattern should treat a percent-encoded segment like some%2Fvalue as a single opaque token rather than splitting it into two path segments at the decoded /. Investigation into why %2F was being decoded and how routes matched against the result surfaced three related security issues, documented below. Rather than landing a fix directly, the problem space warrants discussion first. Different fixes carry different compliance and compatibility tradeoffs, and every viable option is a breaking change in some form. Aligning on a direction before committing to an implementation is the safer path. ## Root cause: two different path representations Go's `net/http` decodes percent-encoded characters when it parses an incoming URL: `%2F` becomes `/` in `r.URL.Path`, while the original encoded form is preserved in `r.URL.RawPath`. Two different parts of s3-proxy use different fields: - The **auth middleware** calls `r.URL.RequestURI()`, which returns the encoded form (from `RawPath` when available). It sees `%2F` as literal characters, not as path separators. - The **bucket handler** reads `r.URL.Path` to build the S3 key. It sees the decoded form, where `%2F` has already become `/`. All three issues stem from this mismatch, combined with how glob patterns are compiled. The examples below use PUT for concreteness, but the auth bypass applies to any HTTP method — a config that restricts GET or DELETE on a namespace is equally affected, meaning an attacker could read from or delete objects in a protected namespace without credentials. ### A note on RFC 3986 RFC 3986 §2.2 states that `/` and `%2F` are **not equivalent** in a URI path: > URIs that differ in the replacement of a reserved character with its > corresponding percent-encoded octet are **not** equivalent. `/` is a reserved gen-delim used as a path segment separator. `%2F` is its percent-encoded form and, by the RFC, should be treated as data *within* a segment — not as a separator. So: - `/foo/bar/baz` → three segments: `foo`, `bar`, `baz` - `/foo%2Fbar/baz` → two segments: `foo/bar` (opaque data), `baz` The original functional concern (wanting `foo%2Fbar` to match as a single token against a single-segment wildcard) is therefore RFC-correct behaviour. Go's `r.URL.Path` violates this by decoding `%2F` to `/`, collapsing the two representations into one. This is the underlying tension that makes fixing these issues non-trivial: the simplest security fix makes s3-proxy *more* RFC non-compliant, while the RFC-correct fix requires a more significant refactor. ### A note on breaking changes Any of the proposed fixes for these issues should be treated as a **breaking change**. Each option alters how path patterns in existing configs are interpreted — whether by changing how `*` matches segments, by shifting which path representation auth matches against, or by normalising paths before they reach the router. Operators upgrading to a fixed version will need to review their resource path definitions, and a clear migration note in the changelog is essential regardless of which approach is chosen. One way to avoid a hard breaking change would be to introduce a new field — for example `route:` — that carries the fixed semantics, while keeping the existing `path:` field with its current behaviour (and marking it deprecated). Operators could migrate resource definitions incrementally, and the security fix would be available immediately without requiring a coordinated config update across all deployments. The obvious cost of this approach is maintaining two parallel implementations, duplicated test coverage, and the ongoing burden of supporting a deprecated code path until it can eventually be removed. --- ## Issue 1 — `*` in resource paths matches across `/` ### Background Resource paths are matched using `github.com/gobwas/glob`. The call site is: ```go // pkg/s3-proxy/authx/authentication/main.go g, err := glob.Compile(res.Path) ``` `glob.Compile` is called **without a separator argument**. Without a separator, `*` matches any character — including `/`. This means a pattern intended to protect a single path segment actually matches across directory boundaries. ### Example Consider a config with an open route and a protected route: ```yaml resources: # open — no auth required - path: /upload/*/drafts/ methods: [PUT] whiteList: true # protected — basic auth required - path: /upload/*/restricted/ methods: [PUT] basic: ... ``` The intent is clear: `drafts` is open, `restricted` is protected. The `*` is meant to match a single path segment (the object identifier). However, because `*` crosses `/`, the pattern `/upload/*/drafts/` also matches: ``` PUT /upload/foo/drafts/../restricted/ ``` The path segment matched by `*` is `foo`, and then `drafts/../restricted/` is consumed by the rest of the pattern — because without a separator, `*` is equivalent to `.*` and matches `/`, `.`, and everything else. The result: an unauthenticated request is accepted by the open route. ### Fix discussion The straightforward fix is to pass `'/'` as the separator to `glob.Compile`: ```go // before g, err := glob.Compile(res.Path) // after g, err := glob.Compile(res.Path, '/') ``` With a separator set: - `*` matches any sequence of non-`/` characters (a single path segment). - `**` matches any sequence including `/` (crossing path boundaries). This fix closes the Issue 1 attack above: with a separator, `drafts/../restricted/` is more than one segment and no longer matches the pattern `/upload/*/drafts/`. #### Breaking change Any existing config that relies on `*` crossing `/` must be updated to `**`. For example: ```yaml # before — worked accidentally because * crossed / - path: /upload/*/drafts/ # after — single-segment match (behaviour unchanged for single-segment IDs) - path: /upload/*/drafts/ # after — multi-segment match (e.g. nested object IDs containing /) - path: /upload/**/drafts/ ``` A migration note in the changelog would be needed. --- ## Issue 2 — Percent-encoded slashes bypass auth via segment collapsing ### Background With Fix 1 applied, `*` only matches a single path segment. However, the auth middleware matches against `r.URL.RequestURI()` — the **encoded** path — while the bucket handler uses `r.URL.Path` — the **decoded** path. A client can use `%2F` to make what looks like a single segment in the encoded URI decode into multiple segments including a protected path component. ### Example Using the same config as Issue 1: ``` PUT /upload/foo%2Frestricted/drafts/ ``` Step by step: 1. `r.URL.RawPath` = `/upload/foo%2Frestricted/drafts/` 2. `r.URL.Path` (decoded) = `/upload/foo/restricted/drafts/` 3. Auth middleware calls `r.URL.RequestURI()` → returns the encoded form. 4. With Fix 1's separator `/`, glob splits on the literal `/`. The segment between the first and second slash is `foo%2Frestricted` — one token with no literal `/` — so `*` matches it. Pattern `/upload/*/drafts/` fires. 5. Open route → request proceeds without auth. 6. Bucket handler uses `r.URL.Path` → S3 key is `upload/foo/restricted/drafts/…` — **written into the restricted namespace without credentials**. ### Proof via integration test I added `TestPercentEncodedSlashBypass` to `pkg/s3-proxy/server/server_integration_test.go`. The test sends a complete multipart PUT without credentials and asserts a 401 response. It currently fails with **204** — the file is written in full to the restricted namespace without any authentication. ### Fix discussion This issue has two fundamentally different classes of fix, each with a different stance on RFC 3986 compliance. #### Option A — Match auth against the decoded path (`r.URL.Path`) Change the auth middleware to use `r.URL.Path` instead of `r.URL.RequestURI()`: ```go // before requestURI := r.URL.RequestURI() // after requestURI := r.URL.Path ``` Both auth and the bucket handler now operate on the same decoded string, closing the mismatch that enables the bypass. **Pros:** One-line change; no other code touched; closes the bypass completely. **Cons:** RFC 3986 non-compliant — `/foo%2Fbar/baz` and `/foo/bar/baz` become indistinguishable at the auth layer. A pattern like `/upload/*/drafts/` will match both `PUT /upload/foo/drafts/` and `PUT /upload/foo%2F.../drafts/` identically after decoding, making it impossible for operators to write a pattern that distinguishes the two. Any path segment containing a literal `/` encoded as `%2F` can never be matched as a single token by `*`. #### Option B — Use the raw path in both auth and key construction Keep `r.URL.RequestURI()` in the auth middleware (reverting the Option A change) and replace the bucket handler's decoded path extraction with `r.URL.EscapedPath()` stripped of the mount path prefix. The AWS SDK then handles percent-encoding the key in the HTTP request to S3, with no manual segment splitting required. This keeps `%2F` opaque at both layers: auth matches against the encoded form, and the S3 key preserves the encoded characters verbatim. **Security mechanism:** the bypass attack (`PUT /upload/foo%2Frestricted/drafts/`) still returns **204** — the open route genuinely matches, because `foo%2Frestricted` is one encoded segment and `*` accepts it. However, the key written to S3 is `upload/foo%2Frestricted/drafts/…` — a distinct namespace from `upload/foo/restricted/drafts/…`. The attacker cannot reach the protected prefix because `%2F` and `/` are treated as different characters all the way to storage. **AWS S3 compatibility confirmed:** S3 natively supports `%2F` in key names. A key `upload/foo%2Fbar/file.txt` is stored and retrieved as a distinct object from `upload/foo/bar/file.txt`. All four operations (HEAD, GET, PUT, DELETE) work correctly with `%2F`-containing paths. **Pros:** RFC-compliant; `%2F` remains a meaningful encoding — `foo%2Fbar` is one token and `*` correctly matches it as a single segment; `/foo%2Fbar/baz` and `/foo/bar/baz` are distinct at both auth and storage layers; simpler than it sounds — no custom segment-splitting utility needed, just `r.URL.EscapedPath()` in the handler. The breaking change is **contained to config files, not clients**: the only clients that break are those relying on `*` crossing literal `/` — and those require a config change to `**` under any fix option. Clients that encode user input containing `/` as `%2F` in a path segment are preserved: `foo%2Fbar` is still one encoded segment, and `*` still matches it. Under Option A those same clients break — the decoded form splits into multiple segments that no longer match `*`. The required client-side fix would be to filter or transform any `/` out of user input before building the URL, which may not always be feasible if the `/` carries meaning. **Cons:** The auth middleware reverts to using the encoded path, which re-opens the door to dot-segment bypass (Issue 3) if the path-cleaning middleware is not also in place — the two fixes must be applied together. A note on the 204 response: a request like `PUT /upload/foo%2Frestricted/drafts/` returns 204 under this option, which may look like a bypass at first glance. It is not. If `%2F` carries meaning, `foo%2Frestricted` is a valid identifier indistinguishable from any other — the server has no basis to treat it as suspicious. The correct security responsibility is to handle all inputs consistently and safely, not to guess intent based on the content of user-provided values. The namespace separation guarantee satisfies that: whatever the client sends is handled the same way at both the auth and storage layers. #### Option C — Reject requests containing `%2F` in the path Return 400 Bad Request for any request whose raw path contains `%2F`: ```go if strings.Contains(r.URL.RawPath, "%2F") || strings.Contains(r.URL.RawPath, "%2f") { http.Error(w, "Bad Request", http.StatusBadRequest) return } ``` **Pros:** Simplest possible enforcement; eliminates the ambiguity entirely. **Cons:** Breaks any client that sends object names containing `/` encoded as `%2F`; rules out a legitimate and RFC-sanctioned use of percent-encoding. --- ## Issue 3 — Dot-dot segments bypass authentication with prefix patterns ### Background Issues 1 and 2 both involve `*` (single-segment wildcard). A different class of bypass survives Fix 1 and Fix 2 when configs use prefix-style patterns with `**` at the end, such as `/open/**`. This is a natural and common pattern for "allow everything under this prefix." The `**` token is explicitly designed to cross `/`, so `..` traversal within that prefix still reaches protected paths. Note that `%2F..%2F` encoded traversal is a variant of this issue: the decoded form (`/../`) contains dot segments that `**` can consume, as described in the root cause section. ### Example Consider this config: ```yaml resources: # protected — basic auth required for anything under /restricted/ - path: /restricted/** methods: [PUT] basic: ... # open — no auth required for anything under /open/ - path: /open/** methods: [PUT] whiteList: true ``` Without any path normalization, the following request bypasses auth: ``` PUT /open/../restricted/secret.json ``` Step by step: 1. Go's `net/url` resolves dot segments when parsing the request URI: `r.URL.Path` is `/restricted/secret.json`. The raw form `../` is preserved only in `r.URL.RawPath`. 2. The auth middleware calls `r.URL.RequestURI()`, which returns the encoded form — `/open/../restricted/secret.json` — and evaluates resources against that. 3. `/restricted/**` does not match because the raw path does not start with `/restricted/`. 4. `/open/**` matches: `**` is allowed to cross `/`, so it consumes `../restricted/secret.json`. 5. The open route fires — no auth required — the request returns 204. 6. The bucket handler reads `r.URL.Path` — already `/restricted/secret.json` — and writes the file directly into the restricted namespace. **Confirmed against AWS S3**: the file lands at `restricted/secret.json` — not at a key containing `../`. Go resolves the dot segments before the bucket handler runs, so the write goes straight into the protected prefix. This makes the attack more severe than a key-naming anomaly: it is a direct, confirmed write into the restricted namespace with no authentication. ### Proof via integration test I added `TestPathTraversalDoubleStarPrefix` to `pkg/s3-proxy/server/server_integration_test.go`. It uses the exact config above and shows that, with a path-cleaning middleware applied **before** the auth middleware, the traversal returns 401 instead of 204: ```go { // /open/** still matches /open/../restricted/file because ** crosses '/'. // cleanPathMiddleware resolves the path to /restricted/file first, which // matches the protected resource -> 401. // Without cleanPathMiddleware this would return 204 (auth bypassed). name: "traversal from open to restricted via ** prefix pattern is blocked", inputMethod: "PUT", inputURL: "http://localhost/open/../restricted/file.txt", expectedCode: 401, }, ``` ### Note on `%2E` (percent-encoded dots) Go's `net/http` decodes `%2E` → `.` in `r.URL.Path` before any middleware runs, so `%2E%2E` arrives as `..` by the time any of the options below apply. All options operate on the already-decoded `r.URL.Path` and therefore handle encoded dots without any extra work. ### Fix discussion All options below address the same root problem: `r.URL.RequestURI()` preserves dot segments while `r.URL.Path` has already resolved them, and auth sees the un-resolved form. The options differ in where the resolution happens and how invasive the change is. #### Option A — Reject requests containing dot segments Reject (400 Bad Request) any request whose decoded path contains `/./` or `/../`: ```go func rejectDotSegmentsMiddleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { p := r.URL.Path if strings.Contains(p, "/./") || strings.Contains(p, "/../") || strings.HasSuffix(p, "/.") || strings.HasSuffix(p, "/..") { http.Error(w, "Bad Request", http.StatusBadRequest) return } next.ServeHTTP(w, r) }) } ``` **Pros:** Simple, explicit, no normalization side-effects. **Cons:** Rejects requests that some clients may legitimately send (though dot segments in HTTP paths are unusual and ill-advised). #### Option B — Use `path.Clean` ```go func cleanPathMiddleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { p := r.URL.Path cleaned := path.Clean(p) if cleaned != p { r2 := r.Clone(r.Context()) r2.URL.Path = cleaned r2.URL.RawPath = "" next.ServeHTTP(w, r2) return } next.ServeHTTP(w, r) }) } ``` `path.Clean` resolves `..` and `.`, collapses double slashes, and also removes the trailing slash. The trailing-slash removal is a breaking change for any config that uses paths ending in `/` — resource patterns, mount paths, or anything else matched against the incoming path. A request to `/upload/foo/drafts/` would be cleaned to `/upload/foo/drafts`, and any pattern or handler that expects the trailing slash would no longer match. This can be mitigated by restoring the trailing slash after cleaning: ```go if len(p) > 1 && p[len(p)-1] == '/' { cleaned += "/" } ``` **Implementation note:** An approach that stores the cleaned path in the request context rather than modifying `r.URL.Path` and clearing `r.URL.RawPath` will not work: both the auth middleware and the bucket handler read from `r.URL` directly, so a context-stored override is invisible to them. **Pros:** Uses the standard library; less custom code. **Cons:** The trailing-slash removal is mitigable by restoring the trailing slash after cleaning (as shown above), but it adds a correctness requirement to the middleware that is easy to overlook — omitting it silently breaks any config using trailing-slash patterns, which is the default convention in s3-proxy examples and documentation. --- ## Interaction between Issue 2 and Issue 3 fixes The choice made for Issue 2 affects the tradeoffs for Issue 3: - If **Option A** is chosen for Issue 2 (auth uses `r.URL.Path`), then dot segments have already been resolved by Go before any middleware runs, so Issue 3 is partially addressed without any additional middleware — but Option A's RFC non-compliance tradeoff still applies. - If **Option B** is chosen for Issue 2 (raw path in both layers), the auth middleware sees the encoded form, which still contains literal `../` dot segments. Issue 3 is **not** addressed by Option B alone — one of the Issue 3 options must also be applied. Importantly, whichever dot-segment option is chosen must clear `r.URL.RawPath` when it modifies the path, so that `r.URL.EscapedPath()` in the bucket handler reflects the cleaned path. This works naturally with both Issue 3 options (which operate on `r.URL.Path` and clear `RawPath`), and the fixes compose cleanly in practice. - In all cases, an explicit dot-segment policy (reject or resolve) is clearer than relying on Go's implicit resolution as a side-effect. --- ## Combined effect | Attack | Issue 1 fix | Issue 2 fix | Issue 3 fix | |---|---|---|---| | `*` crosses `/` (`/upload/*/drafts/` matches `../restricted/`) | Fixed | — | — | | `%2F` segment injection (`foo%2Frestricted/drafts/` bypasses `*/restricted/`) | No | Fixed | — | | `..` traversal via `**` prefix pattern (`/open/../restricted/`) | No | No | Fixed | | `%2F..%2F` encoded traversal (decoded `..` consumed by `**`) | No | Fixed* | Fixed | \* Issue 2's fix (auth using decoded path, Option A) also prevents `%2F`-encoded dot segments from being treated as opaque tokens, so the decoded `..` is visible to the glob before matching. --- ## Suggested combination of fixes - **Issue 1:** Pass `'/'` as the separator to `glob.Compile`. Unambiguously correct; `*` should never have crossed `/`. - **Issue 2:** Option B — use the raw path (`r.URL.EscapedPath()`) in both the auth middleware and the bucket handler. This is the only option that avoids client-side breaking changes for operators whose clients encode user input containing `/` as `%2F`. The security guarantee is namespace separation, which is the right model: the server has no basis to distinguish a legitimate `%2F`-encoded identifier from one that "looks like" a traversal attempt, so consistent handling at both layers is the correct responsibility boundary. - **Issue 3:** Option B — `cleanPathMiddleware` using `path.Clean` with trailing slash restored. Required when using Issue 2 Option B, since auth still sees the raw path. The two fixes compose cleanly: the middleware modifies `r.URL.Path` and clears `r.URL.RawPath`, so `r.URL.EscapedPath()` in the bucket handler reflects the cleaned path. The combined breaking change is limited to config files: operators need to replace `*` with `**` wherever multi-segment wildcard matching is intended. Client-facing URLs require no changes. --- ## Resources - `pkg/s3-proxy/authx/authentication/main.go` — `findResource`, the `glob.Compile` call - `pkg/s3-proxy/server/server_integration_test.go` — `TestPercentEncodedSlashBypass`, `TestPathTraversalDoubleStarPrefix`, `TestPathCleaning` - `github.com/gobwas/glob` — separator documentation - RFC 3986 §2.2 — equivalence of percent-encoded reserved characters - RFC 3986 §3.3 — path segment semantics - RFC 3986 §5.2.4 — dot-segment resolution in URI paths

الإصدارات المتأثرة

All versions < 1320e4abd46a

نوع الثغرة

CWE-22 — Path Traversal

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

المراجع

الوصف الكامل

## Summary The `cleanUpString()` method in `ConfigWriter.php` uses an ungreedy regex to strip Liquidsoap string interpolation patterns (`#{...}`) from user input. This regex can be bypassed via nested interpolation syntax (`#{#{EXPR}}`), allowing injection of arbitrary Liquidsoap code. Commit `ff49ef4` migrated most user-controlled fields to the safe `toRawString()` method but left the remote relay password field using the vulnerable `cleanUpString()`. A user with the `RemoteRelays` station permission can achieve arbitrary code execution in the Liquidsoap process, leak internal API keys, or disrupt station operation. ## Details ### The Vulnerable Sanitizer `cleanUpString()` at `backend/src/Radio/Backend/Liquidsoap/ConfigWriter.php:1349-1367`: ```php public static function cleanUpString(?string $string): string { $string = str_replace(['"', "\n", "\r"], ['\'', '', ''], $string ?? ''); // Remove strings that are interpolated $string = preg_replace( '/#{(.*)}/U', // Ungreedy: matches minimum chars to first } '$1', $string ); $string = preg_replace( '/\$\((.*)\)/U', '$1', $string ?? '' ); return $string ?? ''; } ``` The `/U` (ungreedy) flag causes `.*` to match the **minimum** characters until the first `}`. With nested input `#{#{EXPR}}`: 1. Regex finds `#{` at position 0 2. Ungreedy `.*` matches `#{EXPR` (stops at the **first** `}`) 3. Full match consumed: `#{#{EXPR}` — replacement with capture group `$1` yields: `#{EXPR` 4. The trailing `}` is appended by the regex engine (it was outside the match) 5. **Final result: `#{EXPR}`** — a valid Liquidsoap string interpolation expression ### The Incomplete Patch Commit `ff49ef4` ("Use raw strings for user-input strings to avoid interpolation", 2026-03-06) correctly migrated host, username, mount, name, description, genre, and URL fields to `toRawString()`. However, the password field was left using `cleanUpString()`: `ConfigWriter.php:1208-1215`: ```php $password = self::cleanUpString($source->password); // Still vulnerable $adapterType = $source->adapterType; if (FrontendAdapters::Shoutcast === $adapterType) { $password .= ':#' . $id; } $outputParams[] = 'password = "' . $password . '"'; // Double-quoted = interpolated ``` The password is embedded in a Liquidsoap **double-quoted string**, which evaluates `#{...}` interpolation expressions. ### Why toRawString() Is Safe `toRawString()` uses Liquidsoap raw string delimiters (`{str_xxxxx|...|str_xxxxx}`) which **do not perform interpolation**, making them immune to this attack class. ### The Input Path 1. Attacker sends `PUT /api/station/{station_id}/remote/{id}` with `source_password` containing the nested payload 2. Entity setter truncates to 100 chars via `mb_substr` (payloads fit within this limit) 3. No validation on password content 4. On station config regeneration, `ConfigWriter::getOutputString()` calls `cleanUpString()` on the password 5. Bypass produces valid interpolation, embedded in double-quoted Liquidsoap string 6. Liquidsoap evaluates the interpolation when loading the config ## PoC ### Step 1: API Key Disclosure (38 chars) ```bash # Set malicious password on an existing remote relay curl -X PUT "http://azuracast.local/api/station/1/remote/1" \ -H "X-API-Key: $API_KEY" \ -H "Content-Type: application/json" \ -d '{"source_password": "#{#{settings.azuracast.api_key()}}"}' ``` After `cleanUpString()` processing, the password becomes `#{settings.azuracast.api_key()}`. When Liquidsoap loads the config, the generated line: ``` password = "#{settings.azuracast.api_key()}" ``` evaluates to the internal API key value, which is then sent as the password to the remote relay server — observable by the attacker if they control the relay endpoint. ### Step 2: Remote Code Execution (54 chars) ```bash # RCE payload using string.char() to bypass quote filtering curl -X PUT "http://azuracast.local/api/station/1/remote/1" \ -H "X-API-Key: $API_KEY" \ -H "Content-Type: application/json" \ -d '{"source_password": "#{#{process.run(string.char(105)^string.char(100))}}"}' ``` After processing: `#{process.run(string.char(105)^string.char(100))}` → executes `id` command. `string.char()` and the `^` concatenation operator are used to build the command string without double quotes (which `cleanUpString` replaces with single quotes, and Liquidsoap doesn't support single-quoted strings). ### Step 3: Trigger config regeneration Restart the station or modify any station setting to force Liquidsoap config regeneration. The payload executes when Liquidsoap loads the new config. The same bypass works with `$($(EXPR))` via the second regex `/\$\((.*)\)/U`. ## Impact - **Arbitrary code execution** within the Liquidsoap process container via `process.run()` - **Internal API key disclosure** via `settings.azuracast.api_key()`, granting the attacker full internal API access to the station - **File read/write** within the Liquidsoap container via Liquidsoap's file operations - **Station disruption** — malicious config can crash the Liquidsoap process - **Low privilege bar** — requires only the `RemoteRelays` station permission, not global admin ## Recommended Fix Replace `cleanUpString()` with `toRawString()` for the password field, consistent with the fix applied to all other fields in commit `ff49ef4`. The Shoutcast suffix append needs adjustment to work with raw strings: ```php // Before (vulnerable): $password = self::cleanUpString($source->password); $adapterType = $source->adapterType; if (FrontendAdapters::Shoutcast === $adapterType) { $password .= ':#' . $id; } $outputParams[] = 'password = "' . $password . '"'; // After (safe): $password = $source->password ?? ''; $adapterType = $source->adapterType; if (FrontendAdapters::Shoutcast === $adapterType) { $password .= ':#' . $id; } $outputParams[] = 'password = ' . self::toRawString($password); ``` This uses the raw string delimiter which prevents all interpolation, matching the approach already used for host, username, mount, and all other user-controlled fields. Additionally, consider removing `cleanUpString()` entirely or marking it as deprecated, since `toRawString()` is the correct approach for all Liquidsoap string values. Any remaining callers should be migrated.

الإصدارات المتأثرة

All versions < 0.10.0, 0.10.1, 0.10.2, 0.10.3, 0.10.4

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

### Summary Missing error handling could lead an authenticated Incus user to cause a daemon crash through the import of a truncated storage bucket backup file. ### Details It was found that TransferManager.UploadAllFiles iterates over tar entries but only checks for io.EOF from tr.Next(). When tr.Next() returns a non-EOF error, such as unexpected EOF from a truncated archive, the header hdr is nil and the code continues to access hdr.Name, causing a nil-pointer dereference that panics the daemon. This may allow the Incus daemon to be crashed during S3 bucket restore if a truncated or corrupted backup archive is provided. A panic can occur when a malformed archive produces a non-EOF tar read error after the first entry. Any caller of UploadAllFiles that processes attacker-controlled archive content may be affected. Affected File: [https://github.com/lxc/incus/blob/v6.22.0/…server/storage/s3/transfer_manager.go#L127](https://github.com/lxc/incus/blob/v6.22.0/internal/server/storage/s3/transfer_manager.go#L127) The tar-iteration loop only checks for EOF: Affected Code: ``` for { hdr, err := tr.Next() if err == io.EOF { break // End of archive. } // Skip index.yaml file if hdr.Name == "backup/index.yaml" { ``` When tr.Next() returns a non-EOF error, hdr is nil. The code does not check for this case and immediately dereferences hdr.Name. This was confirmed as follows: Command: ``` go test ./test/fuzz -run='FuzzS3BucketUploadTarParsing/s3_nil_deref_truncated_tar' -count=1 -v ``` Output: ``` === RUN FuzzS3BucketUploadTarParsing === RUN FuzzS3BucketUploadTarParsing/s3_nil_deref_truncated_tar s3_bucket_upload_fuzz_test.go:82: UploadAllFiles panicked: runtime error: invalid memory address or nil pointer dereference --- FAIL: FuzzS3BucketUploadTarParsing/s3_nil_deref_truncated_tar (0.00s) FAIL ``` It is recommended to add a non-EOF error check after tr.Next(). Proposed Fix: ``` hdr, err := tr.Next() if err == io.EOF { break } if err != nil { return fmt.Errorf("Error reading backup archive: %w", err) } ``` A patch is available at https://github.com/lxc/incus/releases/tag/v7.0.0. ### Credits This issue was discovered and reported by the team at 7asecurity (https://7asecurity.com/)

الإصدارات المتأثرة

All versions < 0

نوع الثغرة

CWE-476 — NULL Pointer Deref

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

### Impact Users who use Azure AD remote write with OAuth authentication are impacted. The `client_secret` field in the Azure AD remote write OAuth configuration (`storage/remote/azuread`) was typed as `string` instead of `Secret`. Prometheus redacts fields of type `Secret` when serving the configuration via the `/-/config` HTTP API endpoint. Because the field was a plain string, the Azure OAuth client secret was exposed in plaintext to any user or process with access to that endpoint. ### Patches The problem has been patched by changing `ClientSecret` in `OAuthConfig` to `Secret`. Users should upgrade to 3.11.3 or 3.5.3 LTS. ### Workarounds Users who can not upgrade can switch to Managed Identity or Workload Identity authentication for Azure AD remote write, which do not involve a client secret.

الإصدارات المتأثرة

All versions < 0.311.3

نوع الثغرة

CWE-200 — Info Disclosure

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

المراجع

الوصف الكامل

A vulnerability has been found in osrg GoBGP up to 4.3.0. This impacts the function SRv6L3ServiceAttribute.DecodeFromBytes of the file pkg/packet/bgp/prefix_sid.go of the component SRv6 L3 Service. Such manipulation of the argument data leads to denial of service. The attack may be performed from remote. Upgrading to version 4.4.0 will fix this issue. The name of the patch is f9f7b55ec258e514be0264871fa645a2c3edad11. Users should upgrade the affected component.

الإصدارات المتأثرة

4.4.0

نوع الثغرة

CWE-404 — CWE-404

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

المراجع

الوصف الكامل

A vulnerability has been found in innocommerce InnoShop up to 0.7.8. The affected element is the function InstallServiceProvider::boot of the file innopacks/install/src/InstallServiceProvider.php of the component Installation Endpoint. The manipulation leads to improper authentication. Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used. The identifier of the patch is 45758e4ec22451ab944ae2ae826b1e70f6450dc9. It is recommended to apply a patch to fix this issue.

نوع الثغرة

CWE-287 — Auth Bypass

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

المراجع

الوصف الكامل

Buffer overflow vulnerability in Open Vehicle Monitoring System 3 (OVMS3) 3.3.005. In canformat_pcap.cpp , the parser's phdr.len field is not properly validated, allowing remote attackers to cause a denial of service or possibly execute arbitrary code via crafted PCAP input.

نوع الثغرة

CWE-121 — Stack Overflow

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

Buffer overflow vulnerability in Open Vehicle Monitoring System 3 (OVMS3) 3.3.005. In canformat_gvret.cpp, the length field in GVRET binary data is not properly validated, allowing remote attackers to cause a denial of service or possibly execute arbitrary code via crafted GVRET frames.

نوع الثغرة

CWE-121 — Stack Overflow

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

المراجع

الوصف الكامل

A vulnerability was detected in AcademySoftwareFoundation OpenImageIO up to 3.2.0.1-dev. This vulnerability affects unknown code of the file src/dds.imageio/ddsinput.cpp of the component DDS Image Handler. The manipulation results in out-of-bounds write. The attack needs to be approached locally. The exploit is now public and may be used. The patch is identified as 94ec2deec3e3bf2f2e2ff84d008e27425d626fe2. Applying a patch is advised to resolve this issue.

نوع الثغرة

CWE-119 — Buffer Overflow

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L

المراجع

الوصف الكامل

An issue was discovered in OpenStack ironic-python-agent 1.0.0 through 11.5.0. Ironic Python Agent (IPA) sometimes executes grub-install from within a chroot of the deployed partition image, leading to code execution in the case of a malicious image.

الإصدارات المتأثرة

1.0.0 - 11.5.0

نوع الثغرة

CWE-829 — Untrusted Module

CVSS Vector

CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

المراجع

الوصف الكامل

An issue was discovered in OpenStack Keystone 13 through 29. POST /v3/credentials did not validate that the caller-supplied project_id for an EC2-type credential matched the project of the authenticating application credential. This allowed an attacker holding an unrestricted application credential for project A to create an EC2 credential targeting project B; a subsequent /v3/ec2tokens exchange would then issue a Keystone token scoped to project B while still carrying the original app_cred_id, enabling cross-project lateral movement within the credential owner's role footprint.

الإصدارات المتأثرة

13.0.0 - 19.0.0

نوع الثغرة

CWE-863 — Incorrect Authorization

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:L

المراجع

الوصف الكامل

### Summary `OpenTelemetry.Resources.Azure` reads unbounded HTTP response bodies from the Azure VM remote instance metadata service endpoint into memory. This would allow an attacker-controlled endpoint or one acting as a Man-in-the-Middle (MitM) to cause excessive memory allocation and possible process termination (via Out of Memory (OOM)). ### Details The [`AzureVmMetaDataRequestor`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Resources.Azure/AzureVmMetaDataRequestor.cs) class makes HTTP requests to the relevant Azure VM instance metadata service (`http://169.254.169.254`) to obtain metadata about the running process and its infrastructure. An attacker who controls the configured endpoint, or who can intercept traffic to them (MiTM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an `OutOfMemoryException` that terminates the process. ### Impact Denial of Service (DoS). An attacker can destabilize or crash the application by forcing unbounded memory allocation through the Azure VM instance metadata HTTP response paths. ### Mitigating Factors The application's reachable Azure VM metadata endpoint needs to behave maliciously or be subject to MitM. In normal usage response bodies should not be excessively large. ### Patches Fixed in `OpenTelemetry.Resources.Azure` version `1.15.0-beta.2`. The fix (#4121) introduce changes that introduce limits to `HttpClient` requests so that the response body is streamed rather than buffered entirely in memory. Responses greater than 4 MiB are ignored. ### Workarounds - Disable the Azure VM resource detector. - Use network-level controls (firewall rules, mTLS, service mesh) to prevent Man-in-the-Middle (MitM) attacks on the Azure VM instance metadata endpoint. ### References - [#4121](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4121)

الإصدارات المتأثرة

<= 1.15.0-beta.1

نوع الثغرة

CWE-770 — Resource Exhaustion

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

Jenkins Microsoft Entra ID (previously Azure AD) Plugin versions 666.v6060de32f87d and earlier do not restrict the redirect URL after login. This allows attackers to perform phishing attacks by having users go to a Jenkins URL that will forward them to a different site after successful authentication. Microsoft Entra ID (previously Azure AD) Plugin 667.v4c5827a_e74a_0 only redirects to relative (Jenkins) URLs.

الإصدارات المتأثرة

666.v6060de32f87d

نوع الثغرة

CWE-601 — Open Redirect

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

المراجع

الوصف الكامل

OpenStack Ironic through 25.0.0 allows ipmitool execution in a non-default configuration that has a console interface.

الإصدارات المتأثرة

All versions < 0.0, 10.1.10, 10.1.7, 10.1.8, 10.1.9

نوع الثغرة

CWE-829 — Untrusted Module

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

Parsing logic flaws cause non-signature data to be misidentified as valid signatures when processing malformed form field hierarchies, leading to invalid memory writes and program crashes during internal data structure construction.

الإصدارات المتأثرة

14.0.0 - 14.0.4

نوع الثغرة

CWE-20 — Input Validation

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

A vulnerability was found in choieastsea simple-openstack-mcp up to 767b2f4a8154cca344344b9725537a58399e6036. The affected element is the function exec_openstack of the file server.py. The manipulation results in os command injection. It is possible to launch the attack remotely. The exploit has been made public and could be used. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. The project was informed of the problem early through an issue report but has not responded yet.

نوع الثغرة

CWE-77 — Command Injection

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

المراجع

الوصف الكامل

Incomplete path traversal fixes in awslabs/tough before tough-v0.22.0 allow remote authenticated users with delegated signing authority to write files outside intended output directories via absolute target names in copy_target/link_target, symlinked parent directories in save_target, or symlinked metadata filenames in SignedRole::write, because write paths trust the joined destination path without post-resolution containment verification. We recommend you upgrade to tough-v0.22.0 / tuftool-v0.15.0.

نوع الثغرة

CWE-22 — Path Traversal

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L

المراجع

الوصف الكامل

### Summary Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path. ### Impact The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject. ### Impacted Versions: tough 0.9.0 through 0.21.x, tuftool through 0.14.x ### Patches This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. ### Workarounds No workarounds to this issue are known. ### References * CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue. ### Acknowledgement Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

الإصدارات المتأثرة

All versions < 0.22.0

نوع الثغرة

CWE-345 — CWE-345

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L

المراجع

الوصف الكامل

### Summary Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata. ### Impact The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid. ### Patches This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. ### Workarounds No workarounds to this issue are known. ### References * CVE-2026-6966 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue. ### Acknowledgement Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

نوع الثغرة

CWE-347 — CWE-347

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N

المراجع

الوصف الكامل

Improperly controlled modification of dynamically-determined object attributes in the Cognito User Pool configuration in AWS Ops Wheel before PR #165 allows remote authenticated users to escalate to deployment admin privileges and manage Cognito user accounts via a crafted UpdateUserAttributes API call that sets the custom:deployment_admin attribute. To remediate this issue, users should redeploy from the updated repository and ensure any forked or derivative code is patched to incorporate the new fixes.

نوع الثغرة

CWE-915 — CWE-915

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

Missing JWT signature verification in AWS Ops Wheel allows unauthenticated attackers to forge JWT tokens and gain unintended administrative access to the application, including the ability to read, modify, and delete all application data across tenants and manage Cognito user accounts within the deployment's User Pool, via a crafted JWT sent to the API Gateway endpoint. To remediate this issue, users should redeploy from the updated repository and ensure any forked or derivative code is patched to incorporate the new fixes.

نوع الثغرة

CWE-347 — CWE-347

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

Delta Electronics AS320T has denial of service via the undocumented subfunction vulnerability.

نوع الثغرة

CWE-912 — Backdoor

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

Delta Electronics AS320T has no checking of the length of the buffer with the directory name vulnerability.

نوع الثغرة

CWE-121 — Stack Overflow

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

Delta Electronics AS320T has No checking of the length of the buffer with the file name vulnerability.

نوع الثغرة

CWE-121 — Stack Overflow

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

Delta Electronics AS320T has incorrect calculation of the buffer size on the stack in the GET/PUT request handler of the web service.

نوع الثغرة

CWE-131 — CWE-131

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

## Summary Host execution env sanitization did not block `GIT_TEMPLATE_DIR` or `AWS_CONFIG_FILE`, even though both can redirect trusted tooling to attacker-controlled content. ## Impact An approved exec request could redirect git or AWS CLI behavior through attacker-controlled configuration and execute untrusted code or load attacker-selected credentials. ## Affected Component `src/infra/host-env-security-policy.json, src/infra/host-env-security.ts` ## Fixed Versions - Affected: `<= 2026.3.24` - Patched: `>= 2026.3.28` - Latest stable `2026.3.28` contains the fix. ## Fix Fixed by commit `6eb82fba3c` (`Infra: block additional host exec env keys`). OpenClaw thanks @nicky-cc of Tencent zhuque Lab [https://github.com/Tencent/AI-Infra-Guard](https://github.com/Tencent/AI-Infra-Guard) for reporting.

الإصدارات المتأثرة

2026.3.28

نوع الثغرة

CWE-184 — CWE-184

CVSS Vector

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:N

المراجع

الوصف الكامل

## Summary The `fetch()` call for remote images in `packages/integrations/cloudflare/src/utils/image-binding-transform.ts` (line 28) uses the default `redirect: 'follow'` behavior. This allows the Cloudflare Worker to follow HTTP redirects to arbitrary URLs, bypassing the `isRemoteAllowed()` domain allowlist check which only validates the initial URL. All three other image fetch paths in the codebase correctly use `{ redirect: 'manual' }`. This is an incomplete fix for GHSA-qpr4-c339-7vq8. Confirmed on HEAD. ## Root Cause `image-binding-transform.ts` line 28: const content = await (isRemotePath(href) ? fetch(imageSrc) : assets.fetch(imageSrc)); Missing `{ redirect: 'manual' }`. The three protected paths: // image-passthrough-endpoint.ts:23 response = await fetch(href, { redirect: 'manual' }); // assets/endpoint/shared.ts:11 const res = await fetch(src, { redirect: 'manual' }); // assets/utils/remoteProbe.ts:53 const response = await fetch(url, { redirect: 'manual' }); ## PoC Demonstrated with Node.js that `fetch()` without `redirect: 'manual'` follows 302 redirects to arbitrary destinations: # Server A (allowed domain) returns 302 → Server B (internal) fetch('http://allowed:19741/img.jpg') → follows 302 → hits http://internal:19742/secret fetch('http://allowed:19741/img.jpg', {redirect:'manual'}) → returns 302, internal server NOT hit Attack path: attacker finds an open redirect on an allowed domain, crafts `/_image?href=https://allowed-cdn.com/redirect?url=http://internal-service/`, and the Worker follows the redirect to the unauthorized destination. ## Impact Bypasses the `image.domains` and `image.remotePatterns` allowlist for the default Cloudflare image service (`cloudflare-binding`). Enables blind SSRF to domains not in the allowlist. Same vulnerability class as GHSA-qpr4-c339-7vq8 (HIGH) which fixed the passthrough endpoint but missed this one. ## Suggested Fix const content = await (isRemotePath(href) ? fetch(imageSrc, { redirect: 'manual' }) : assets.fetch(imageSrc));

الإصدارات المتأثرة

< 13.1.10

نوع الثغرة

CWE-918 — SSRF

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L

المراجع

الوصف الكامل

go-ntlmssp is a Go package that provides NTLM/Negotiate authentication over HTTP. Prior to version 0.1.1, a malicious NTLM challenge message can causes an slice out of bounds panic, which can crash any Go process using `ntlmssp.Negotiator` as an HTTP transport. Version 0.1.1 patches the issue.

الإصدارات المتأثرة

< 0.1.1

نوع الثغرة

CWE-190 — Integer Overflow

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

المراجع

الوصف الكامل

### Summary `OpenTelemetry.Sampler.AWS` reads unbounded HTTP response bodies from a configured AWS X-Ray remote sampling endpoint into memory. `OpenTelemetry.Resources.AWS` reads unbounded HTTP response bodies from a configured AWS EC2/ECS/EKS remote instance metadata service endpoint into memory. Both of these would allow an attacker-controlled endpoint or be acting as a Man-in-the-Middle (MitM) to cause excessive memory allocation and possible process termination (via Out of Memory (OOM)). ### Details #### OpenTelemetry.Sampler.AWS `AWSXRaySamplerClient.DoRequestAsync` called `HttpClient.SendAsync` followed by `ReadAsStringAsync()`, which materializes the entire HTTP response body into a single in-memory string with no size limit. The sampling endpoint is configurable via `AWSXRayRemoteSamplerBuilder.SetEndpoint` (default: `http://localhost:2000`). An attacker who controls the configured endpoint, or who can intercept traffic to it (MitM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an `OutOfMemoryException` that terminates the process. #### OpenTelemetry.Resources.AWS The [`AWSEC2Detector`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Resources.AWS/AWSEC2Detector.cs), [`AWSECSDetector`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Resources.AWS/AWSECSDetector.cs) and [`AWSEKSDetector`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Resources.AWS/AWSEKSDetector.cs) classes all make HTTP requests to the relevant AWS metadata service (`http://169.254.169.254`, `ECS_CONTAINER_METADATA_URI`/`ECS_CONTAINER_METADATA_URI_V4` or `https://kubernetes.default.svc` respectively) to obtain metadata about the running process and its infrastructure. An attacker who controls the configured endpoint(s), or who can intercept traffic to them (MiTM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an `OutOfMemoryException` that terminates the process. ### Impact Denial of Service (DoS). An attacker can destabilize or crash the application by forcing unbounded memory allocation through the X-Ray sampling and/or EC2/ECS/EKS HTTP response paths. ### Mitigating Factors - The default X-Ray sampling endpoint is `http://localhost:2000`, which limits remote exposure in default configurations. - Risk increases materially when operators configure the sampler to point at a remote or untrusted endpoint. ### Patches Fixed in `OpenTelemetry.Sampler.AWS` version `0.1.0-alpha.8` and `OpenTelemetry.Resources.AWS` version `1.15.1`. The fixes (#4100, #4122) introduce changes that introduce limits to `HttpClient` requests so that the response body is streamed rather than buffered entirely in memory. ### Workarounds - Ensure the X-Ray sampling endpoint (`http://localhost:2000` by default) is not accessible to untrusted parties. - Use network-level controls (firewall rules, mTLS, service mesh) to prevent Man-in-the-Middle (MitM) attacks on the sampling endpoint and/or EC2/ECS/EKS connection. - If using a remote endpoint, place it behind a reverse proxy that enforces a response body size limit.

الإصدارات المتأثرة

< 0.1.0-alpha.8, < 1.15.1

نوع الثغرة

CWE-770 — Resource Exhaustion

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

A Generation of Error Message Containing Sensitive Information vulnerability in the Materialized View Refresh mechanism in Google BigQuery on Google Cloud Platform allows an authenticated user to potentially disclose sensitive data using a crafted materialized view that triggers a runtime error during the refresh process. This vulnerability was patched on 29 January 2026, and no customer action is needed.

نوع الثغرة

CWE-209 — Info Disclosure

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Clear

المراجع

الوصف الكامل

### Impact _What kind of vulnerability is it? Who is impacted?_ An authentication bypass vulnerability in MinIO's `STREAMING-UNSIGNED-PAYLOAD-TRAILER` code path allows any user who knows a valid access key to write arbitrary objects to any bucket without knowing the secret key or providing a valid cryptographic signature. Any MinIO deployment is impacted. The attack requires only a valid access key (the well-known default `minioadmin`, or any key with WRITE permission on a bucket) and a target bucket name. `PutObjectHandler` and `PutObjectPartHandler` call `newUnsignedV4ChunkedReader` with a signature verification gate based solely on the presence of the `Authorization` header: ```go newUnsignedV4ChunkedReader(r, true, r.Header.Get(xhttp.Authorization) != "") ``` Meanwhile, `isPutActionAllowed` extracts credentials from either the `Authorization` header or the `X-Amz-Credential` query parameter, and trusts whichever it finds. An attacker omits the `Authorization` header and supplies credentials exclusively via the query string. The signature gate evaluates to `false`, `doesSignatureMatch` is never called, and the request proceeds with the permissions of the impersonated access key. This affects `PutObjectHandler` (standard and tables/warehouse bucket paths) and `PutObjectPartHandler` (multipart uploads). **Affected components:** `cmd/object-handlers.go` (`PutObjectHandler`), `cmd/object-multipart-handlers.go` (`PutObjectPartHandler`). ### Affected Versions All MinIO releases through the final release of the minio/minio open-source project. The vulnerability was introduced in commit [`76913a9fd`](https://github.com/minio/minio/commit/76913a9fd5c6e5c2dbd4e8c7faf56ed9e9e24091) ("Signed trailers for signature v4", [PR #16484](https://github.com/minio/minio/pull/16484)), which added `authTypeStreamingUnsignedTrailer` support. The first affected release is `RELEASE.2023-05-18T00-05-36Z`. ### Patches **Fixed in**: MinIO AIStor RELEASE.2026-04-11T03-20-12Z #### Binary Downloads | Platform | Architecture | Download | | -------- | ------------ | --------------------------------------------------------------------------- | | Linux | amd64 | [minio](https://dl.min.io/aistor/minio/release/linux-amd64/minio) | | Linux | arm64 | [minio](https://dl.min.io/aistor/minio/release/linux-arm64/minio) | | macOS | arm64 | [minio](https://dl.min.io/aistor/minio/release/darwin-arm64/minio) | | macOS | amd64 | [minio](https://dl.min.io/aistor/minio/release/darwin-amd64/minio) | | Windows | amd64 | [minio.exe](https://dl.min.io/aistor/minio/release/windows-amd64/minio.exe) | #### FIPS Binaries | Platform | Architecture | Download | | -------- | ------------ | --------------------------------------------------------------------------- | | Linux | amd64 | [minio.fips](https://dl.min.io/aistor/minio/release/linux-amd64/minio.fips) | | Linux | arm64 | [minio.fips](https://dl.min.io/aistor/minio/release/linux-arm64/minio.fips) | #### Package Downloads | Format | Architecture | Download | | ------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | DEB | amd64 | [minio_20260411032012.0.0_amd64.deb](https://dl.min.io/aistor/minio/release/linux-amd64/minio_20260411032012.0.0_amd64.deb) | | DEB | arm64 | [minio_20260411032012.0.0_arm64.deb](https://dl.min.io/aistor/minio/release/linux-arm64/minio_20260411032012.0.0_arm64.deb) | | RPM | amd64 | [minio-20260411032012.0.0-1.x86_64.rpm](https://dl.min.io/aistor/minio/release/linux-amd64/minio-20260411032012.0.0-1.x86_64.rpm) | | RPM | arm64 | [minio-20260411032012.0.0-1.aarch64.rpm](https://dl.min.io/aistor/minio/release/linux-arm64/minio-20260411032012.0.0-1.aarch64.rpm) | #### Container Images ```bash # Standard docker pull quay.io/minio/aistor/minio:RELEASE.2026-04-11T03-20-12Z podman pull quay.io/minio/aistor/minio:RELEASE.2026-04-11T03-20-12Z # FIPS docker pull quay.io/minio/aistor/minio:RELEASE.2026-04-11T03-20-12Z.fips podman pull quay.io/minio/aistor/minio:RELEASE.2026-04-11T03-20-12Z.fips ``` #### Homebrew (macOS) ```bash brew install minio/aistor/minio ``` ### Workarounds - [Users of the open-source `minio/minio` project should upgrade to MinIO AIStor `RELEASE.2026-04-11T03-20-12Z` or later.](https://docs.min.io/enterprise/aistor-object-store/upgrade-aistor-server/community-edition/) If upgrading is not immediately possible: - **Block unsigned-trailer requests at the load balancer.** Reject any request containing `X-Amz-Content-Sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER` at the reverse proxy or WAF layer. Clients can use `STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER` (the signed variant) instead. - **Restrict WRITE permissions.** Limit `s3:PutObject` grants to trusted principals. While this reduces the attack surface, it does not eliminate the vulnerability since any user with WRITE permission can exploit it with only their access key. ### Credits - **Finder:** Arvin Shivram of Brutecat Security ([@ddd](https://github.com/ddd))

الإصدارات المتأثرة

2023-05-18t00-05-36z - 2026-04-11T03-20-12Z

نوع الثغرة

CWE-287 — Auth Bypass

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

المراجع

الوصف الكامل

## Summary AWS Encryption SDK (ESDK) for Python is a client-side encryption library. An issue exists where, under certain circumstances, a specific cryptographic algorithm downgrade in the caching layer might allow an authenticated local threat actor to bypass key commitment policy enforcement via a shared key cache, resulting in ciphertext that can be decrypted to multiple different plaintexts. ## Impact This issue requires all of the following conditions to be true: (1) Two ESDK for Python clients with different commitment policies share a single CachingCryptoMaterialsManager instance within the same process. (2) The client with the weaker commitment policy encrypts first, warming the cache. (3) Both clients use matching encryption contexts. (4) Both clients use the pre-configured default algorithm suite. These conditions may occur during a migration from ESDK for Python v1 to newer versions, as v1 did not support key commitment. When the weaker-policy client encrypts first, the cache stores encryption materials that do not enforce key commitment. Subsequent callers — including those configured to require key commitment — are served these cached materials instead of generating new ones that satisfy their policy. This results in encryption without key commitment, meaning the same ciphertext can be validly decrypted to different plaintexts under different keys (the "Invisible Salamanders" issue; see https://github.com/google/security-research/security/advisories/GHSA-wqgp-vphw-hphf). A threat actor who controls ciphertext can cause a recipient to decrypt a message different from what the sender encrypted, breaking message integrity. ## Impacted versions - From 2.0 to 2.5.1 - From 3.0 to 3.3.0 - From 4.0 to 4.0.4 ## Patches This issue has been addressed in ESDK for Python versions 3.3.1 and 4.0.5. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. ## Workarounds If a customer requires operating multiple instances of the Python ESDK each with differently configured key commitment policies, they must not share a key cache. References If there are any questions or comments about this advisory, contact AWS Security through the [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue. ## Acknowledgement Thanks to [1seal.org](http://1seal.org/) for collaborating on this issue through the coordinated vulnerability disclosure process.

الإصدارات المتأثرة

>= 2.0.0, < 3.3.0, >= 4.0.0, < 4.0.4

نوع الثغرة

CWE-757 — CWE-757

CVSS Vector

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N

المراجع

الوصف الكامل

The wpForo Forum plugin for WordPress is vulnerable to Arbitrary File Deletion in versions up to and including 3.0.5. This is due to two compounding flaws: the Members::update() method does not validate or restrict the value of file-type custom profile fields, allowing authenticated users to store an arbitrary path instead of a legitimate upload path; and the wpforo_fix_upload_dir() sanitization function in ucf_file_delete() only remaps paths that match the expected pattern, and it is passed directly to the unlink() function. This makes it possible for authenticated attackers, with subscriber-level access and above, to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php). Note: The vulnerability requires a file custom field, which requires the wpForo - User Custom Fields addon plugin.

نوع الثغرة

CWE-22 — Path Traversal

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

المراجع