The Extensions for Leaflet Map plugin for WordPress is vulnerable to Stored DOM-Based Cross-Site Scripting via the 'feature.properties[<template-token>]' parameter in all versions up to, and including, 5.4 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. Exploitation requires that a site administrator has previously configured a public map using the [leaflet-map]+[leaflet-geojson]+[choropleth] shortcode combination whose GeoJSON src URL is one the attacker controls — for example, through compromise of an external data host, a subdomain takeover, or a site intentionally pointing at an attacker-hosted feed.
### Summary
In affected versions, the SDK's server-side bearer authentication had no way to check that a token was issued for your server (its audience). Where one authorization server issues tokens for several services, a valid token for another service was also accepted by your MCP server.
### Am I affected?
Yes, if your HTTP server uses the SDK's bearer authentication (`auth=AuthSettings(...)` with `token_verifier=`), its authorization server also issues tokens for other services, and your `TokenVerifier` does not check the token's audience (`aud`) itself.
Affected versions:
- `mcp` 1.10.0 through 1.29.1
- `mcp` 2.0.0 through 2.1.1
### Fix
Upgrade to:
- 1.x: `mcp` 1.30.0 or later
- 2.x: `mcp` 2.2.0 or later
**Upgrading alone changes nothing.** The patched versions add a `validate_token_resource` setting that is off unless you set it. To turn the check on, make both of these changes together:
1. Set `validate_token_resource=True` in `AuthSettings`, with `resource_server_url` set to the audience your authorization server puts in tokens for your server.
2. Return the token's audience from `verify_token()` as `AccessToken.resource`.
A token for another service then gets `401`. With only the first change, every request gets `401`.
If your `TokenVerifier` already checks the audience, set `validate_token_resource=False` to silence the deprecation warning. The setting will default to `True` in 3.0.
If you cannot upgrade yet, reject any token whose `aud` does not include your server inside `verify_token()`. That closes the issue on every version.
A security vulnerability in the sudo utility allows bypass of time-based authorization controls via the TZ environment variable. This flaw affects certain Red Hat Enterprise Linux 8.4 packages and permits users to circumvent NOTBEFORE/NOTAFTER restrictions. A security update addressing this issue is available from Red Hat.
Kaspersky has fixed a vulnerability in the Network Agent for Windows module of Kaspersky Security Center. The vulnerability could potentially cause the Network Agent module of Kaspersky Security Center to malfunction. There are no evidence of the vulnerability exploitation in-the-wild.
An incorrect authorization vulnerability in GitLab EE versions from 12.0 up to but not including 19.3.6, 19.4 up to 19.4.3, and 19.5 up to 19.5.1 allowed authenticated users to grant or accept project and group memberships outside the identity provider's control when the instance-wide SAML or LDAP membership lock was enabled. This was due to incomplete enforcement of the membership lock on requests created before the lock was enabled. The issue has been fixed in versions 19.3.6, 19.4.3, and 19.5.1.
GitLab versions from 10.1 up to but not including 19.3.6, 19.4 up to 19.4.3, and 19.5 up to 19.5.1 contain an LDAP injection vulnerability. This flaw occurs when OmniAuth SAML and LDAP auto-linking are both enabled, allowing an authenticated user to take over an existing LDAP-backed account without interaction from the targeted user due to improper input sanitization in the LDAP email lookup during OmniAuth identity linking. The issue has been fixed in GitLab versions 19.3.6, 19.4.3, and 19.5.1.
A vulnerability in GitLab Enterprise Edition versions from 17.4 up to but not including 19.3.6, 19.4 up to but not including 19.4.3, and 19.5 up to but not including 19.5.1 could allow an authenticated user to bypass a required merge request approval policy on a protected branch. This occurs due to improper access control during approval rule synchronization. The issue has been fixed in versions 19.3.6, 19.4.3, and 19.5.1.
A vulnerability in GitLab CE/EE versions from 15.10 up to but not including 19.3.6, 19.4 up to 19.4.3, and 19.5 up to 19.5.1 allows an authenticated user to bypass authorization checks and read milestone metadata from arbitrary private projects without membership. The flaw is due to missing authorization on a user-controlled project filter parameter in the group milestones API. This issue has been fixed in versions 19.3.6, 19.4.3, and 19.5.1.
GitLab CE/EE versions from 18.2 up to but not including 19.3.6, 19.4 up to 19.4.3, and 19.5 up to 19.5.1 contain an authorization flaw. An authenticated user with a read_api-scoped token could bypass token restrictions to retrieve a project's incoming email address and create work items due to insufficient scope enforcement on a GraphQL field. This issue has been fixed in versions 19.3.6, 19.4.3, and 19.5.1.
A vulnerability in GitLab Enterprise Edition versions from 17.8 up to but not including 19.3.6, 19.4 up to but not including 19.4.3, and 19.5 up to but not including 19.5.1 allowed authenticated users to access paid AI features without a valid subscription. This was due to insufficient server-side validation in billing eligibility checks. The issue has been fixed in versions 19.3.6, 19.4.3, and 19.5.1.
An issue in GitLab EE versions from 17.8 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 allowed authenticated users with read-only permissions to permanently delete existing vulnerability records due to improper cleanup logic during error handling. This flaw has been remediated in versions 19.3.6, 19.4.3, and 19.5.1.
GitLab versions from 18.3 up to but not including 19.3.6, 19.4 up to 19.4.3, and 19.5 up to 19.5.1 contain a vulnerability where an unauthenticated user could poison a shared cache's OAuth/OIDC discovery document. This occurs due to improper trust of user-supplied values when constructing endpoint URLs in cached discovery responses, potentially redirecting flows to an attacker-controlled server. The issue has been fixed in versions 19.3.6, 19.4.3, and 19.5.1.
A critical integer overflow vulnerability exists in GitLab CE/EE versions from 7.0 up to certain patched releases before 18.11.13 and 19.x series before specific patch versions. This flaw could allow an unauthenticated attacker to execute arbitrary code on the GitLab server by exploiting an integer overflow during the compilation of a specially crafted regular expression.
A vulnerability in GitLab CE/EE versions from 17.6.5 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 allowed an unauthenticated user to retrieve sensitive internal server credentials due to improper filtering of internal response headers. This issue has been fixed in versions 19.3.6, 19.4.3, and 19.5.1.
A vulnerability in GitLab CE/EE versions from 15.0 up to but not including 19.3.6, 19.4 up to 19.4.3, and 19.5 up to 19.5.1 allowed authenticated users without project membership to read confidential issue titles from private projects when referenced in merge requests of public projects. This occurred due to a cache key that improperly shared rendered content across users, exposing sensitive information.
GitLab EE versions 19.2 up to but not including 19.3.6, 19.4 up to 19.4.3, and 19.5 up to 19.5.1 contain an authorization flaw. This flaw allows an authenticated user with group Owner permissions to bypass an instance administrator's lock on a group's Duo availability and re-enable AI-backed data egress to a third-party service for that group and its descendant projects. The issue arises from insufficient granularity in the enforcement of admin-lock controls. GitLab has released fixes in versions 19.3.6, 19.4.3, and 19.5.1.
Docker Engine contains a vulnerability in its handling of insecure registries where a DNS response containing both a loopback IP and a non-loopback attacker IP can bypass certificate verification and enable HTTP fallback. This occurs because the insecure registry check uses an any-match DNS approach that considers a hostname insecure if any resolved address matches an insecure CIDR, but the transport reconnects using the hostname rather than the matched address. This flaw is fixed in Docker Engine version 18.09.0-355.oe2203sp4.
FreeRDP versions before 2.11.8-11.oe2403sp4 contain multiple security vulnerabilities including heap buffer overflows, out-of-bounds reads, and uninitialized heap memory disclosures. These flaws arise from improper validation and handling of RDP protocol messages such as Server Redirection PDUs, URBDRC channel messages, and RPC gateway transport parser data. Exploitation can lead to client crashes, denial of service, information disclosure, and potentially remote code execution when combined with other vulnerabilities. The issues are fixed in version 2.11.8-11.oe2403sp4.