Pangolin is the authoritative index of a data lake and holds cloud storage credentials. We take reports seriously and would rather hear about a problem early than read about it later.

Do not open a public issue for a security problem.

Report privately through GitHub's private vulnerability reporting on this repository. If that is unavailable to you, email the maintainer listed in Cargo.toml with PANGOLIN SECURITY in the subject line.

Please include:

• what an attacker can do, and what they need in order to do it (network position, an account, a specific role);
• the affected version or commit;
• a reproduction — a request sequence, a script, or a failing test is ideal;
• your assessment of the impact.

We will keep you informed while we work, credit you in the advisory unless you prefer otherwise, and tell you before we publish. If we disagree that something is a vulnerability we will explain why rather than going quiet.

Pangolin is pre-1.0 and moves fast. Only the latest minor release receives security fixes.

Every version before 0.7.0 is affected by a privilege-escalation vulnerability and should not be run. Upgrade to 0.7.0 and rotate every issued token. The findings below come from a full-repo audit conducted the day after the 0.6.0 release; the authorization cluster was outside that release's scope and is new information, not a regression.

Note which version you are actually running. The published container image alexmerced/pangolin-api was last pushed at 0.5.1 — no 0.6.0 image was ever released — so most deployments are on 0.5.1, which carries everything described here and everything 0.6.0 fixed. The affected range is < 0.7.0, not 0.6.0 alone.

Every issue in this table needs nothing but a valid credential — including the lowest-privilege tenant-user account, or any service-user API key.

Not security boundaries, but silent corruption is worth the same attention:

• B5 MongoDB's update_metadata_location ignored the compare-and-swap entirely. Two concurrent Iceberg commits both reported success and one snapshot was lost. Memory, Postgres and SQLite all enforced it.
• B3 SQLite's delete_branch referenced a column that does not exist and was not transactional: the branch was committed away and its assets orphaned permanently, while the caller received an error suggesting nothing happened.
• B7 All three persistent backends stored the Debug spelling of AssetType and parsed only two of seventeen variants. A DeltaTable, MlModel or Lance asset round-tripped as an Iceberg table.
• B4 Postgres decoded a TEXT[] column as String; sqlx::Row::get panics on a decode failure, so any search returning at least one hit panicked the request.

The aws-sts, azure-oauth and gcp-oauth features - and the cloud-credentials bundle that unions them - did not compile, at any version. cargo build and cargo test run with default features and no job ever passed --features, so the entire cloud-credential surface had rotted into code that could not be built at all: parameters bound as _name and referenced as name inside the cfg block, a missing macro import, and an STS expiry parsed from a DateTime as though it were an RFC3339 string.

This is not an exploitable defect - unbuildable code ships in no binary. It matters because it means STS-based credential vending was not running anywhere, so any deployment that believed it was handing out scoped, time-limited credentials was not. Check what your warehouses are actually configured with: if use_sts is set but the server was built without the feature (which is to say, always), the static-credential fallback in S3Signer::generate_credentials is what answered - vending your long-lived warehouse keys, with no expiry, instead of a scoped session token. Where no static keys were configured either, the call failed with "AWS credentials not configured", which at least failed closed.

Fixed in 0.7.0, with a CI job that builds every optional feature so it cannot recur silently.

• To 0.8.0: docs/upgrading/0.7-to-0.8.md — MSRV 1.94, PANGOLIN_ENCRYPTION_KEY, MongoDB uniqueness constraints that can fail on existing duplicates, rate limiting behind a proxy, and OIDC.

1. Rotate every issued token. B0a means any account may have minted a Root token, and B0j means logging out never invalidated anything. Rotating PANGOLIN_JWT_SECRET invalidates all existing sessions at once and is the fastest way to be sure.
2. Rotate service-user API keys, for the same reason: B0g allowed expired keys to keep issuing fresh JWTs.
3. Rotate any cloud storage credentials reachable through a warehouse that an untrusted tenant member could name. B0b vended them to anyone.
4. Audit for the escalation. POST /api/v1/tokens calls from non-admin principals, and credential-vending calls for tables the caller had no grant on, are the two signals. Note that on SQLite there is no audit history to check, and on MongoDB action-filtered queries returned nothing (B23) — so a clean audit log is not evidence of absence on those backends.
5. Check PANGOLIN_NO_AUTH and PANGOLIN_DEV_MODE. If both were set on a non-loopback bind, treat the deployment as having been open to anonymous tenant-admin access for that period. The server now refuses to start in that configuration.
6. Set PANGOLIN_OAUTH_EMAIL_LINK_DOMAINS if you rely on OAuth accounts being matched to existing local users by email. Without it, identity is (provider, subject) only and an address never adopts an existing account — which is the safe default, and a behaviour change.
7. On SQLite, upgrading migrates the audit_logs table to schema version 2. The previous table is preserved as audit_logs_pre_v2; it is empty in practice, because nothing could ever write to it.
8. Third-party API clients may need changes. Server request bodies now reject unknown fields with 422 instead of silently ignoring them. If a client sent a misspelled or obsolete field, it was already being discarded — the request was never doing what it appeared to.

0.6.0 is a security release. If you run anything earlier, upgrade and rotate credentials. The following were exploitable:

Correctness defects fixed in the same release — silent data loss rather than a security boundary, but worth knowing about if you ran concurrent writers:

• A-1 assert-ref-snapshot-id was never enforced, so a writer whose compare-and-swap lost would retry and re-apply its snapshot onto a branch that had moved on: forked snapshot lineage and orphaned data files, with no error ever surfaced.
• A-2 Eleven commit update types were discarded while returning 200 OK.
• A-3 last_sequence_number was assigned a snapshot ID, which can produce incorrect query results on merge-on-read tables.

1. Set PANGOLIN_JWT_SECRET to a real secret (openssl rand -base64 48). The server now refuses to start without one, and rejects known placeholders. Changing it invalidates every existing session — which you want, because any token issued under the old default was forgeable.
2. Rotate service-user API keys. Keys are now issued in a pgl_<key-id>_<secret> format that makes lookup O(1). Pre-existing keys keep working only if you set PANGOLIN_ALLOW_LEGACY_API_KEYS=true, which reintroduces the scan and should be temporary.
3. Set PANGOLIN_OAUTH_REDIRECT_URIS if you use OAuth. Redirect targets are now allowlisted, and the token is delivered by a one-time code exchange rather than a URL parameter — see docs/operations/oidc.md for the client change.
4. Review your audit log for tenant_impersonation, login_failed and api_key_rejected events, which are recorded from 0.6.0 onward.

Before exposing Pangolin to anything you care about:

• PANGOLIN_JWT_SECRET is at least 32 bytes of real entropy and is not in Git. Prefer existingSecret in the Helm chart over values.yaml.
• PANGOLIN_NO_AUTH is unset. It grants tenant-admin to anonymous callers; the server refuses to start with it enabled on a non-loopback address, but do not rely on that.
• PANGOLIN_DEV_MODE is unset.
• PANGOLIN_ROOT_USER is unset unless you actively need root basic auth.
• TLS is terminated in front of the server. Pangolin binds plain HTTP.
• PANGOLIN_CORS_ALLOWED_ORIGINS is set. The default allows any origin, which is only safe behind a trusted gateway.
• PANGOLIN_ALLOW_LEGACY_API_KEYS is unset once keys are rotated.
• Containers run as non-root with a read-only root filesystem — the shipped chart defaults do this; confirm you have not overridden them.
• Database backups are encrypted. Warehouse rows contain cloud storage credentials in the clear; envelope encryption at rest is not yet implemented (C-11).
• /metrics is not exposed publicly. It is unauthenticated by design for scraping; set PANGOLIN_METRICS_ENABLED=false if you cannot restrict it.

The full reconciled list, including non-security work, is in STATUS.md.

Stated plainly, because a checklist that hides its limits is worse than none:

• Rate limiting is in-process, so it is per replica. The authentication endpoints are throttled from 0.7.0, per source address and per account, but the counters are not shared between replicas: with N replicas an attacker gets N times the configured budget. A shared limiter needs Redis or equivalent, which this project does not otherwise require.
• OIDC applies only to providers that support it. Google, Microsoft, Okta and any IdP configured via PANGOLIN_<PROVIDER>_ISSUER get PKCE, id_token signature validation via JWKS, and iss/aud/exp/nonce checks. GitHub issues no id_token, so its logins still rest on the userinfo endpoint; set PANGOLIN_OIDC_REQUIRE=true to refuse any provider that cannot be OIDC-validated. No back-channel logout, no refresh-token handling, and the PKCE verifier is held in process so OAuth needs session affinity.
• Symmetric HS256 JWTs with no key rotation. Rotating the secret invalidates every session at once.
• Warehouse credentials are encrypted at rest only when a key is set. PANGOLIN_ENCRYPTION_KEY enables AES-256-GCM sealing of the credential fields; unset, they are plaintext and the server warns at startup. The key lives in the server environment, so this protects a stolen database and not a compromised host.
• Audit records are not tamper-evident. They live in the same database as application data, with no hash chaining and no WORM option.
• No MFA, password policy, or account lockout.
• Eight dependency advisories are accepted rather than fixed, each with its reasoning recorded in .cargo/audit.toml. None is reachable in a default build, but they are exceptions rather than absences: rsa (never compiled), quick-xml (held back by object_store 0.11 and azure_core 0.20), a second rustls-webpki arriving via the AWS SDK's rustls 0.21, http-types, and rand's custom-logger unsoundness. Re-check the list when dependencies move.

These are tracked in AUDIT_EXECUTION_PLAN.md (items C-2 through C-20).