[advisories] ignore = [ # paste unmaintained — transitive via azure_core 0.21.0 (latest available). # No direct security impact; no upgrade path exists. # keep warning "RUSTSEC-2024-0436", # rand 0.7.3 unsound — transitive via http-types → azure_core 0.21.0. # Only exploitable with a custom logger using rand::rng(); not applicable here. "RUSTSEC-2026-0097", # RUSTSEC-2023-0071 (Marvin Attack): rsa crate is a transitive dependency from jsonwebtoken. # Not affected: This application uses HS256 for internal JWT signing and only performs # RSA public key verification (not private key operations) for OIDC/OAuth2 tokens. "RUSTSEC-2023-0071", # rustls-webpki 0.101.7 — three advisories, all transitive via AWS SDK → rustls 0.21.12. # aws-sdk-s3 1.x (latest) has not yet migrated to rustls 0.23.x; no upgrade path available. # Severity: low — exploitation requires either a rogue CA or a MitM on AWS S3 infrastructure. # RUSTSEC-2026-0104: DoS via panic in CRL parsing (only if CRLs are processed). # RUSTSEC-2026-0098: URI name constraints ignored (requires CA misissuance). # RUSTSEC-2026-0099: Wildcard name constraint bypass (requires CA misissuance). "RUSTSEC-2026-0104", "RUSTSEC-2026-0098", "RUSTSEC-2026-0099", # h2 0.3.27 — RUSTSEC-2026-0258 "unbounded empty DATA frames" # (GHSA-q83h-524g-xf6h). Transitive via aws-smithy-http-client 1.1.12 # → hyper 0.14.32 → h2 0.3.27. The patched line is 0.4.16+, but hyper # 0.14's `h2 = "0.3"` requirement pins us to the 0.3.x branch which # will not receive a backport — real fix requires aws-smithy-http-client # to migrate to hyper 1.x (which our other h2 copy — 0.4.16, already # bumped — is on). The 0.4.x copy is fixed via `cargo update`; this # ignore covers only the 0.3.x chain. # # Severity: low (advisory's own classification). Attack is empty-DATA- # frame flooding by a malicious HTTP/2 peer → memory pressure or panic. # In this codebase h2 0.3.x runs strictly on the CLIENT side of AWS # SDK requests to S3 endpoints. Exploitation requires either # compromising AWS S3 (out-of-scope) or MitM with a valid TLS cert # for the configured S3 host (bigger problem than the DoS). No # data-integrity or auth impact; panic path contained by # request-level unwind. # # Un-ignore trigger: aws-smithy-http-client releases a version that # switches to hyper 1.x (checkable with `cargo tree -i h2@0.3` — the # command returns no rows once the chain is gone). Track upstream at # https://github.com/smithy-lang/smithy-rs/issues (search "hyper 1"). "RUSTSEC-2026-0258", # instant unmaintained — transitive via azure_core 0.21.0 (latest available). # No direct security impact; no upgrade path exists. "RUSTSEC-2024-0384", # quick-xml 0.31.0 — transitive via azure_core 0.21.0 (unofficial SDK, # now archived). Our direct dep is already on 0.41.0; the 0.31 copy is # only reachable through the azure_storage_blobs chain, which parses # XML responses received from Azure Storage over TLS. Neither CVE is # exploitable without attacker-controlled XML, so the vector requires # MitM of the TLS channel to Azure (or a compromised storage # endpoint). Real fix is migrating to the official azure_core 1.0 / # azure_storage_blob 1.0 SDK — tracked separately. # RUSTSEC-2026-0195: unbounded ns-declaration allocation → mem-DoS # RUSTSEC-2026-0194: quadratic dup-attribute check → CPU-DoS "RUSTSEC-2026-0195", "RUSTSEC-2026-0194", # azure_core 0.21.0 — "Legacy azure_core writes the authorization # header value to logs" (RUSTSEC-2026-0275, 6.5 medium). Same # unofficial archived SDK, same absent upgrade path as the other # 0.21.0-chain advisories above: the advisory's "upgrade to # >=0.22.0" applies to the official azure_core crate line, not to # the archived 0.21.0 we're pinned on via the unofficial # azure_storage_blobs SDK. Real fix is the official azure_core 1.0 / # azure_storage_blob 1.0 SDK migration tracked separately (memory # project_azure_sdk_migration_pending) — blocked upstream by the # 1.0 SDK dropping shared-key auth. # # Exposure in this codebase is narrow. The advisory covers the # HTTP client emitting the `Authorization` header value into log # records; for our Azure backend usage that header value is # `SharedKey :` — the shared key itself # never appears, only a per-request HMAC signature bound to the # request's `x-ms-date` and unusable outside the ~15 min clock-skew # window. Reaching the log path further requires (a) an Azure # backend actually being configured (S3 and local are the # alternatives) and (b) the tracing subscriber emitting DEBUG # records for the `azure_core` target — production defaults are # INFO. Under both conditions the worst-case leak is replay of # individual object operations within the skew window by an # attacker who already has production log read access; the shared # key cannot be derived. # # Un-ignore trigger: the official azure_core 1.0 migration lands — # at which point this entry and the other azure_core 0.21.0-chain # entries above (RUSTSEC-2026-0097, -2024-0384, -2026-0195, # -2026-0194) all go away together. "RUSTSEC-2026-0275", # wasmtime 43.0.2 — "Stores can mix up type indices between engines" # (GHSA-hgjw-h833-99q9). Transitive via extism 1.30.0 (latest published; # extism `main` still pins wasmtime 43, no upgrade path). The advisory # has no patched 43.x — fix requires wasmtime >=46.0.2 or >=47.0.3, and # forcing that via [patch.crates-io] would break extism (three major # wasmtime API bumps between 43 and 46). Real fix waits on extism # upstream to migrate. # # Runtime exposure is zero in default deployments: # - `plugins` is an OPT-IN build feature; default builds and the CI # release binary don't link wasmtime at all. # - Runtime activation additionally requires OXICLOUD_ENABLE_PLUGINS=true. # - Plugin binaries are ADMIN-SUPPLIED, not attacker input. # - The advisory's attack pattern is multi-Engine Store-sharing; # OxiCloud's plugin runtime creates one fresh Plugin per invocation # with its own Store (see infrastructure/services/plugins/runtime.rs). "RUSTSEC-2026-0222", # wasmtime 43.0.2 — "Filesystem sandbox escape when paths or symlinks # contain trailing slashes" (RUSTSEC-2026-0269, 8.8 high). Same crate, # same chain and same absent upgrade path as RUSTSEC-2026-0222 above: # extism 1.30.0 is the latest published and pins wasmtime 43, while the # advisory's fixed releases are >=24.0.13 <25, >=36.0.14 <37, # >=46.0.3 <47, >=47.0.4 — none in the 43.x line, so there is no # version satisfying extism's requirement that carries the fix. # # NOT REACHABLE, and for a stronger reason than the build-feature # gating: this is a WASI filesystem sandbox escape, and OxiCloud's # plugin runtime gives plugins no filesystem to escape from. # `plugins/runtime.rs::compile` builds every plugin with # `.with_wasi(false)` and declares no `allowed_paths`, so there are no # preopened directories — the escape needs one to traverse out of. # `.disallow_all_hosts()` removes outbound network on the same path. # # The build-level gating from the entry above still applies on top: # `plugins` is opt-in and absent from `default`, so the CI release # binary does not link wasmtime; runtime activation additionally needs # OXICLOUD_ENABLE_PLUGINS=true; and plugin binaries are admin-supplied, # not attacker input. # # Un-ignore trigger: EITHER extism releases a version on wasmtime # >=46.0.3 (check with `cargo tree -i wasmtime --features plugins`), # OR `plugins/runtime.rs` gains `allowed_paths` / `with_wasi(true)` — # at which point this stops being unreachable and blocks release # rather than being ignored. "RUSTSEC-2026-0269", # astral-tokio-tar 0.5.6 — tar extraction advisories, transitive via # testcontainers → testcontainers-modules, a DEV-dependency used only by # the `--cfg integration_tests` harness to spin up throwaway Postgres # containers. Never compiled into the production binary and never fed # attacker-controlled tar input — the only archives extracted are the # official Postgres images the test harness pulls. testcontainers 0.25.2 # pins astral-tokio-tar to ^0.5, so the fixed 0.6.x is not reachable # without a testcontainers major bump (tracked separately). # RUSTSEC-2026-0145 / -0112: PAX header desynchronization # RUSTSEC-2026-0113: unpack_in symlink-following chmod # RUSTSEC-2026-0066: insufficient PAX extension validation (low) "RUSTSEC-2026-0145", "RUSTSEC-2026-0112", "RUSTSEC-2026-0113", "RUSTSEC-2026-0066", ]