| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Apache Airflow's Config API did not mask team-scoped sensitive configuration values in multi-team deployments. When an administrator has enabled multi-team mode and exposed the Config API, an authenticated Viewer holding only configuration-read access — with no prior access to the secret — could read a team-scoped Celery broker URL, including its embedded credentials, in cleartext, while the equivalent global option was correctly masked. The secrets masker matched only base section and option names and did not normalize team-prefixed sections before the sensitivity check (CWE-200). This is a distinct masker bypass from CVE-2026-48828 and CVE-2026-48892: deployments that upgraded to apache-airflow 3.3.0 to address those issues remain affected by this team-scoped variant. Users are advised to upgrade to apache-airflow 3.3.1 or later, which normalizes team-scoped sections before masking. |
| Apache Airflow's secrets masker did not mask `var.json` Variable values whose value is a dict in the Rendered Templates UI — the dict value failed an `isinstance(str)` guard — so a secret stored as a JSON Variable and referenced in a template via `var.json` was displayed in cleartext to any user with access to that task's Rendered Templates view. Users are advised to upgrade to apache-airflow 3.3.1 or later, which masks nested Variable values regardless of type. |
| SQL injection in the Zalktis accounting application via
trading-partner-controlled text fields in received electronic invoices. When
importing a received e-invoice (UBL/PEPPOL) or an e-commerce export, Zalktis
concatenates partner-controlled values directly into SQL statement text using
string concatenation, with neither parameterised queries nor escaping. The
application's own escaping helper, Dazadi.sql_txt(),
is not invoked on these code paths, so a party that sends an invoice can break
out of the string literal and alter the query logic.
This issue affects Zalktis: before 2026.1.586 and before 2026.2.592. |
| ParseAcceptLanguage quadratic-time DoS via Locale middleware on unauthenticated requests |
| Gitea LFS Deploy-Key Privilege Escalation |
| Private Repository Metadata Remains Accessible After Access Revocation |
| Public-only API token restriction is not enforced on team API routes |
| Public-Only Personal access tokens scope bypass in Organization and Permission Endpoints |
| Release attachment extension allowlist bypass via web release edit form (variant of CVE-2025-68939) |
| Private org member list leaked via /members API endpoint — incomplete fix for PR #38145 |
| OAuth token introspection returns metadata of tokens issued to other clients (RFC 7662 section 4 violation) |
| Local File Inclusion via file:// URI in Migration Restore |
| REST API exposes organization membership of private organizations to public |
| Two SSRF findings in Gitea 1.26.2 |
| Repository Migration Follows Git HTTP Redirects After URL Allow/Block Validation, Enabling Internal Git Repository Exfiltration |
| Cross-repository issue/comment attachment re-linking can expose private attachment content |
| Null Pointer Dereference in AddTime API Causes Authenticated Denial of Service |
| OIDC userinfo Endpoint Returns Identity Claims Without Enforcing API Token Scopes |
| Internal API HTTP client hardcodes InsecureSkipVerify:true with no config override (CWE-295) |
| Apache Airflow's XCom `GET /api/v2/{...}/xcomEntries/{key}?deserialize=true` endpoint passed a string-literal payload through `BaseXCom.deserialize_value` without the `_check_forbidden_xcom_keys` guard, allowing an authenticated API user with XCom write-and-read access to instantiate arbitrary `airflow.*` classes on the API server (CWE-502). An authenticated user who can write an XCom value and then read it back with `deserialize=true` triggers the unsafe instantiation. Users are advised to upgrade to apache-airflow 3.3.1 or later, which rejects reserved XCom serialization keys submitted as JSON string literals. |
