WordPress is a content management system paired with a MySQL or MariaDB database. Features include a plugin architecture and a template system, referred to within WordPress as Themes.

WordPress

WordPress 6.9.x before 6.9.5 and 7.0.x before 7.0.2 is affected by a REST API batch endpoint route confusion issue which, combined with the author__not_in WP_Query SQL Injection (CVE-2026-60137), could allow an attacker to perform SQL Injection and achieve Remote Code Execution.

CVE-2026-63030

Chainguard

Echo

Wolfi

Linux

Linux Kernel

Windows

Windows Cumulative Update

WordPress 6.8.x before 6.8.6, 6.9.x before 6.9.5, and 7.0.x before 7.0.2 does not properly sanitise the author__not_in parameter of WP_Query, which could allow SQL Injection when a plugin or theme passes untrusted input to the parameter.

CVE-2026-60137

SonicWall SMA 8200v Appliance is a secure remote access solution that provides employees and partners with policy-enforced access to critical network resources. It offers SSL VPN connectivity for both managed and unmanaged devices, supporting a wide range of operating systems and browsers.

SonicWall SMA 8200v Appliance

A Server-side request forgery (SSRF) vulnerability has been identified in the SMA1000 Appliance Work Place interface. A remote unauthenticated attacker could potentially cause the appliance to make requests to unintended location.

CVE-2026-15409

NixOS is a Linux distribution built on top of the Nix package manager. It is completely declarative, its system configurations are reproducible, makes configuration changes reliable and atomic, and eliminates configuration drift.

NixOS

Chainguard is a Linux distribution based on Alpine. It's the commercial version of the Wolfi distro.

LiteLLM is an open-source library that provides a unified interface for various large language models (LLMs). It allows developers to easily switch between different LLM providers like OpenAI, Anthropic, and others without changing their code. LiteLLM simplifies the process of working with multiple LLMs by offering a consistent API across different models and providers.

LiteLLM

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.84.0, LiteLLM's MCP Streamable HTTP endpoint allowed an unauthenticated attacker to use a fabricated Authorization header to trigger an OAuth2 passthrough fallback path that replaced failed LiteLLM key validation with an empty UserAPIKeyAuth() object, allowing requests to reach MCP tooling without a valid LiteLLM key. This issue is fixed in version 1.84.0.

CVE-2026-59822

BeyondTrust Privileged Remote Access is a secure remote access solution that enables IT administrators and security professionals to control, audit, and manage privileged access to critical systems by authorized employees and third-party vendors. It minimizes security risks associated with remote access by implementing granular role-based access controls and providing real-time monitoring, logging, and auditing capabilities. The solution integrates with various IT systems and supports multi-factor authentication, ensuring that only authorized users can access resources.

BeyondTrust Privileged Remote Access Client

BeyondTrust Remote Support is a secure remote access solution that enables IT support teams to provide assistance to users and manage devices across multiple platforms. It offers robust security features, including granular access control and session monitoring, to ensure compliance with industry standards. The platform is designed for efficient troubleshooting and enhanced customer support experiences.

BeyondTrust Remote Support Client

BeyondTrust Privileged Remote Access

BeyondTrust Remote Support

A critical pre-authentication vulnerability exists in the authentication subsystem of BeyondTrust Remote Support. Improper processing of authentication requests may allow an unauthenticated remote attacker to bypass access controls and gain unauthorized access to the appliance, including accounts with elevated privileges. Exploitation requires a specific authentication configuration to be enabled.

CVE-2026-40139

PHP is a general-purpose scripting language that is especially suited for web development.

### Impact
When the optional `referer` redirect setting is enabled, affected versions of `RedirectMiddleware` can copy the fragment from the referring request URI into a generated `Referer` header. A URI fragment is the part after `#`. It is handled locally by the client and is not part of the HTTP request target, so the server handling the original request does not receive it. A generated `Referer` tells the redirect destination which URI led to the request. Guzzle correctly removes user information from that value, but retains the fragment when it follows a redirect to the same scheme, such as HTTPS to HTTPS. For example, an initial URI ending in `#secret` is sent without the fragment, but the redirect destination can receive a `Referer` ending in `#secret`. This behavior affects both the cURL and stream handlers.
An attacker who controls the redirect destination can read the fragment from the incoming header, including through request logs or application code. If the fragment contains a one-time login secret, access token, state value, or other private client data, it is disclosed to a server that was never meant to receive it. Exploitation requires the application to enable `allow_redirects.referer`, make a request to a URI with a sensitive fragment, and follow a same-scheme redirect to a less-trusted destination.
The `referer` setting is disabled by default. Applications that leave it disabled, do not put sensitive data in URI fragments, do not follow redirects, or only redirect within the same trust boundary are not affected. Guzzle already omits the generated header when the scheme changes. This issue is limited to the fragment's inclusion. Reducing the path and query on cross-origin redirects is a separate privacy policy question.
### Patches
The issue is patched in `7.15.1` and later. Starting in that release, Guzzle removes both user information and the fragment before generating a redirect `Referer` value. Other redirect behavior does not change. Guzzle retains the referring path and query, and continues to omit the header when the scheme changes. Versions before `7.15.1` are affected when the optional `referer` setting is enabled.
### Workarounds
If you cannot upgrade immediately, leave automatic Referer generation disabled. It is off by default. If redirect options are configured explicitly, ensure that `referer` is `false`:
```php
$client->request('GET', $uri, [
    'allow_redirects' => ['referer' => false],
]);
```
Alternatively, disable automatic redirects and follow trusted destinations manually, or remove the fragment from the request URI before sending a request that may redirect. Do not rely on the fact that fragments are absent from the initial HTTP request target, because the affected middleware can reintroduce them in the generated header.
### References
* https://www.rfc-editor.org/rfc/rfc9110.html#section-10.1.3
* https://www.rfc-editor.org/rfc/rfc3986.html#section-3.5
* https://www.rfc-editor.org/rfc/rfc9700.html#section-4.2.3

GHSA-h95v-h523-3mw8

Composer

GitHub Advisory Database

### Impact
In affected versions, `CookieJar` does not preserve whether a response cookie was set without a `Domain` attribute or with an empty one. A cookie without `Domain` is host-only and must be returned only to the exact host that set it. Under current cookie processing rules, an empty `Domain` value is also host-only. Guzzle instead stores the request host in the cookie's `Domain` field and later applies ordinary domain matching, as though the server had supplied a valid domain. For example, a host-only `sid=secret` cookie set by `example.com` can subsequently be sent to `child.example.com`. `FileCookieJar` and `SessionCookieJar` also persist the request host without recording the host-only state, so reloading a jar preserves the widened scope.
An attacker who controls or can observe a child host can therefore receive cookies that were intended only for its parent host. Depending on the cookie, this can disclose session identifiers, authorization tokens, or other sensitive state. Exploitation requires the application to enable Guzzle's cookie support, reuse the same built-in cookie jar, receive a host-only cookie from a parent host, and later make a matching request to a less-trusted child host. The cookie's other restrictions still apply. Its path must match, a `Secure` cookie is sent only over a secure connection, and an expired cookie is not sent.
Applications that do not use Guzzle's cookie support are not affected. Applications are also not affected by this disclosure if they use a separate jar for every host or trust boundary, never request a less-trusted subdomain with the same jar, or only store cookies carrying a valid, non-empty `Domain` attribute. The incorrect behavior occurs between an otherwise valid parent host and its subdomains.
### Patches
The issue is patched in `7.15.1` and later. Starting in that release, Guzzle records whether a response cookie is host-only and matches it only against the exact host. The host-only flag is part of cookie identity for replacement and response-driven deletion. Cookies carrying a valid, non-empty `Domain` attribute retain their existing domain-matching behavior. A host-only cookie can coexist with an explicit-domain cookie having the same name, domain string, and path.
The built-in persistent jars now write a boolean `HostOnly` marker for every stored cookie record. They reject records where that marker is missing or is not a boolean, and validate all records before changing the live jar. Persisted cookie records written by an older version are therefore rejected rather than silently interpreted with an unsafe scope. Loading non-empty file or session data written without this marker throws a `RuntimeException` until the data is deleted, regenerated, or correctly annotated. Versions before `7.15.1` are affected.
### Workarounds
If you cannot upgrade immediately, do not reuse one `CookieJar` instance across parent and child hosts with different trust levels. Use a separate cookie jar for each host or trust boundary, disable cookie handling for requests to less-trusted hosts, or avoid making those requests through a client configured with a shared jar. In particular, avoid `new Client(['cookies' => true])` for a client that may contact both a trusted parent host and less-trusted subdomains, because that option creates one jar for the whole client.
When upgrading, delete or rotate existing `FileCookieJar` and `SessionCookieJar` data that contains cookie records written without a `HostOnly` marker. Records may instead be annotated manually only when the original presence or absence of the cookie's `Domain` attribute is known. The stored domain string is not sufficient to infer it safely.
### References
* https://www.rfc-editor.org/rfc/rfc10025.html#section-4.1.2.3
* https://www.rfc-editor.org/rfc/rfc10025.html#section-5.7
* https://www.rfc-editor.org/rfc/rfc10025.html#section-5.8.3

GHSA-wm3w-8rrp-j577

### Impact
In affected versions, Guzzle's built-in `CookieJar` accepts any number of `Set-Cookie` header fields from one response, with no limit on the size of each field. When a later request matches the stored cookies, Guzzle places every match into one generated `Cookie` header without limiting the number of cookies or the total header length.
A malicious or compromised server can therefore return many large cookies, causing Guzzle to store attacker-controlled data in memory and copy it into later request headers. This can increase memory use and processing time. It can also make later requests fail when the generated header exceeds a limit in a handler, HTTP implementation, proxy, or destination server. A server on one sibling host, such as `attacker.example.com`, can also set parent-domain cookies that are later selected for another sibling, such as `service.example.com`. The denial can therefore affect a different service that uses the same jar.
An application is affected when it enables the built-in cookie support, receives an attacker-controlled response, and retains or reuses the jar. The issue affects both built-in handlers because Guzzle manages these cookies itself instead of using libcurl's native cookie engine. cURL addressed a similar denial-of-service issue in CVE-2022-32205 by limiting the cookies it accepts and sends, but those native limits do not protect Guzzle's separate jar. Applications that do not use cookies, use separate jars for untrusted origins, or use a third-party `CookieJarInterface` with suitable limits are not affected by this behavior. The demonstrated direct impact is limited to availability. The patch does not impose a lifetime limit on a jar built up over an unlimited number of responses or populated directly by application code.
### Patches
The issue is patched in `7.15.1` and later. Starting in that release, the built-in `CookieJar` ignores a `Set-Cookie` field value longer than 8,190 bytes and applies at most 50 successful cookie insertions or replacements from one response. When generating a request, it emits at most 150 matching `name=value` pairs and limits the complete `Cookie: ` header line to 8,190 bytes, including the field name and following space.
These limits follow the same practical shape as cURL's response to CVE-2022-32205. Both bound cookies accepted from one response, cookies added to one request, and generated header size. Guzzle's 8,190-byte incoming field limit is more generous than cURL's current 5,000-byte cookie-line limit. Neither approach adds a global jar quota or an eviction policy. The 8,190-byte incoming boundary is inclusive. Invalid, unrelated, identical, oversized, and deletion fields do not consume the 50-cookie limit. For outgoing requests, Guzzle preserves its existing matching and iteration order. It stops after 150 pairs or before the first matching cookie that would exceed the line limit. The output limits also apply to directly imported cookie state, but that state is not limited when it is added to the jar. Explicit caller-supplied `Cookie` headers and third-party jar implementations remain the caller's responsibility. Versions before `7.15.1` are affected.
### Workarounds
If you cannot upgrade immediately, do not enable a shared built-in cookie jar for requests to untrusted origins. Use separate jars per host or trust boundary, disable cookie handling for untrusted requests, and discard or clear a jar after receiving an untrusted response before it is reused. Applications that must accept cookies from untrusted peers can provide a custom `CookieJarInterface` implementation that enforces suitable limits.
Guzzle does not use libcurl's cookie engine for cookies stored in a `CookieJar`. The cURL handler sends the `Cookie` header that Guzzle's cookie middleware has already built, so libcurl's cookie limits do not apply. Upgrading libcurl therefore does not fix this issue.
### References
* https://curl.se/docs/CVE-2022-32205.html
* https://www.rfc-editor.org/rfc/rfc10025.html#section-5.7
* https://www.rfc-editor.org/rfc/rfc10025.html#section-5.8.3
* https://www.rfc-editor.org/rfc/rfc10025.html#section-6.1

GHSA-f283-ghqc-fg79

JavaScript is a high-level, interpreted programming language essential for creating interactive web applications, running directly in web browsers to enable dynamic content and user interface enhancements. It is integral to the web development stack, working seamlessly with HTML and CSS to build responsive and feature-rich websites.

JavaScript

## Summary
In the composable `astro/hono` pipeline, the `security.checkOrigin` protection is only installed by the `middleware()` primitive. The `actions()` and `pages()` primitives each dispatch to user code independently, so a pipeline that mounts either primitive before (or without) `middleware()` will bypass the origin check for those requests.
## Details
`security.checkOrigin` (default: `true`) is intended to reject cross-site `POST`/`PUT`/`PATCH`/`DELETE` form submissions. In the classic pipeline (`astro()` all-in-one), the check always runs because Astro injects a virtual middleware module even when the user has no `src/middleware.ts`. In the composable `astro/hono` pipeline, the user assembles primitives manually. The check is only installed inside `middleware()` — so:
- Mounting `actions()` before `middleware()` allows cross-origin form-encoded action requests to execute before the gate runs. The `examples/advanced-routing` example and the Cloudflare `hono` docs shipped this order.
- Omitting `middleware()` entirely (reasonable for apps with no custom middleware) silently drops `checkOrigin` protection for all on-demand endpoints and pages dispatched through `pages()`.
The attack is a blind write-only CSRF: the attacker can trigger a state-mutating action or endpoint handler using the victim's cookies, but cannot read the cross-origin response body.
## Affected versions
Astro `>= 7.0.0` when using the composable `astro/hono` pipeline with either:
- `actions()` mounted before `middleware()`, or
- `pages()` used without `middleware()`
The default (non-composable) pipeline is not affected.
## Fix
The origin check is now applied at each dispatch sink (`ActionHandler.handle` and `PagesHandler.handleWithErrorFallback`), gated on `manifest.checkOrigin`, using the same predicate as the middleware. The check is order-independent and a no-op when `middleware()` has already run.
Fix: https://github.com/withastro/astro/pull/17250
## Workaround
Ensure `middleware()` is mounted before both `actions()` and `pages()` in the composable pipeline, and that it is always included even when no custom middleware logic is needed:
```ts
app.use(middleware());
app.use(actions());
app.use(pages());
```

GHSA-8mv7-9c27-98vc

## Summary
The `@astrojs/netlify` adapter converts each `image.remotePatterns` entry into a regular expression that is written to `.netlify/v1/config.json` under `images.remote_images`. Netlify's Image CDN uses these regexes as the allowlist that decides which remote image URLs it will optimize. `remotePatternToRegex()` escapes `.` in the hostname but interpolates the literal `pathname` into the regex **without escaping regex metacharacters**. As a result, the generated allowlist is broader than the pattern the developer declared, and broader than Astro's canonical `matchPattern()` helper (which compares non-wildcard pathnames by exact string equality).
This is a residual of the same bug class addressed in CVE-2026-54300 (PR #17018, commit `1310277d`). That fix corrected wildcard semantics and added a `$` anchor but did not add metacharacter escaping for literal pathnames.
## Details
In `packages/integrations/netlify/src/index.ts`, `remotePatternToRegex()` escapes dots in the hostname:
```js
regexStr += hostname.replace(/\./g, '\\.');
```
but interpolates the pathname unescaped in all three branches, e.g. the exact-match branch:
```js
regexStr += `(\\${pathname})`;
```
Any regex metacharacter in the literal path (`.`, `+`, `?`, `(`, `[`, ...) is therefore passed through raw. Because `.` matches any character (including `/`), a restrictive pattern is silently widened.
The security boundary on Netlify is the generated regex itself — Netlify's Image CDN enforces it directly and Astro's runtime `matchPattern()` is not in the loop for this path, so there is no compensating layer that re-validates the request.
## Proof of Concept
Configure an SSR site with a literal pathname containing a `.`:
```js
// astro.config.mjs
image: {
  remotePatterns: [{
    protocol: 'https',
    hostname: 'cdn.example.com',
    pathname: '/img/v1.0/file',
  }],
}
```
Run `astro build` and inspect `.netlify/v1/config.json` `images.remote_images[0]`:
```
https://cdn\.example\.com(:[0-9]+)?(\/img/v1.0/file)([?][^#]*)?$
```
Testing the generated regex:
- `https://cdn.example.com/img/v1.0/file` -> MATCH (intended)
- `https://cdn.example.com/img/v1X0/file` -> MATCH (bypass; the unescaped `.` matches any character)
- `https://cdn.example.com/img/v1/0/file` -> MATCH (bypass; `.` also matches `/`, crossing a path segment)
Astro's canonical `matchPattern()` (exact string equality on the pathname) rejects both bypass URLs.
## Impact
Netlify's Image CDN accepts optimization requests for URLs on the allowed host that the developer's `remotePatterns` entry was intended to exclude. The hostname remains correctly anchored, so the broadening is confined to the pathname dimension on an already-allowed host. Realistic impact depends on whether other images the developer meant to keep out of their CDN exist at metacharacter-adjacent paths on that host. This affects reasonable, non-permissive configurations, since any `pathname` containing a `.` (file extensions, version segments) is affected.
## Patches
A fix will escape all regex metacharacters in the literal portions of each `remotePatterns` component before interpolation, applying only Astro's documented wildcard semantics explicitly. A regression corpus validates the generated Netlify regexes against `@astrojs/internal-helpers`' `matchPattern()`.
## Workarounds
Avoid regex metacharacters (notably `.`) in `image.remotePatterns[].pathname` values, or scope the allowed host so that unintended paths are not reachable.
## Credit
Reported by @sec-reex as part of an incomplete-patch measurement study (responsible disclosure).

CVE ID	Gravidade	Pontuação	Tecnologias	Nome do componente	Exploração do CISA KEV	Tem correção	Data de publicação
CVE-2026-63030	CRITICAL	9.8	WordPress	cpe:2.3:a:wordpress:wordpress	Não	Sim	Jul 17, 2026
CVE-2026-60137	MEDIUM	5.9	WordPress	wordpress	Não	Sim	Jul 17, 2026
CVE-2026-15409	CRITICAL	10	SonicWall SMA 8200v Appliance	cpe:2.3:a:sonicwall:sma8200v	Sim	Não	Jul 14, 2026
CVE-2026-59822	HIGH	8.8	NixOS	cpe:2.3:a:litellm:litellm	Não	Sim	Jul 08, 2026
CVE-2026-40139	CRITICAL	9.2	BeyondTrust Privileged Remote Access Client	cpe:2.3:a:beyondtrust:privileged_remote_access	Não	Sim	Jul 06, 2026

CVE ID	Gravidade	Pontuação	Tecnologias	Nome do componente	Exploração do CISA KEV	Tem correção	Data de publicação
GHSA-h95v-h523-3mw8	MEDIUM	5.9	PHP	guzzlehttp/guzzle	Não	Sim	Jul 20, 2026
GHSA-wm3w-8rrp-j577	MEDIUM	5.9	PHP	guzzlehttp/guzzle	Não	Sim	Jul 20, 2026
GHSA-f283-ghqc-fg79	MEDIUM	5.3	PHP	guzzlehttp/guzzle	Não	Sim	Jul 20, 2026
GHSA-8mv7-9c27-98vc	MEDIUM	5.1	JavaScript	astro	Não	Sim	Jul 20, 2026
GHSA-hp3v-mfqw-h74c	LOW	3.7	JavaScript	@astrojs/netlify	Não	Sim	Jul 20, 2026

Banco de dados de vulnerabilidades Wiz

Explore por tecnologia

Filtros populares

Alto perfil

Último

Vulnerabilidades em números

O bom, o mau e o vulnerável

Recursos adicionais da Wiz

PEACH

Pronto para ver a Wiz em ação?