CVE WatchOct 28, 2026

CVE-2026-118691

xianyu-auto-reply-fix through 2.0.7 contains a missing authorization vulnerability in the POST /send-message endpoint that allows unauthenti

CVSS

3.7

Low

EPSS

—

KEV

—

Exploit Today

—

0-100

Published: Oct 28, 2026 · Last modified: Oct 28, 2026 · CWE-1188

EPSS · 30d

Not enough EPSS history yet.

Technical description

xianyu-auto-reply-fix through 2.0.7 contains a missing authorization vulnerability in the POST /send-message endpoint that allows unauthenticated attackers to send messages from other users' accounts using publicly known default API secrets. Attackers can supply the hard-coded api_key and another user's cookie_id, plus chosen chat_id, to_user_id and message values, to send arbitrary Xianyu messages to buyers from that merchant account.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-116273—

—

———MIME::Parser versions before 5.521 for Perl set no limit on the number of message parts by default, allowing memory exhaustion. The max_parts option defaulted to -1, which disables the limit, so a parser created with default settings builds an entity for every part however many a message has. Version 5.521 sets max_parts to 1000 and max_depth to 64 by default. Setting either to -1 still removes the limit.9h CVE-2026-110952—

—

———A Kafka broker that authenticates clients with SASL/OAUTHBEARER using the bundled JWKS-backed validator always verifies the JWT signature, but two further checks are only performed when explicitly configured: - The issuer (iss) claim is verified only when sasl.oauthbearer.expected.issuer is set. When it is unset, a validly-signed token carrying the expected audience is accepted regardless of which issuer minted it. - An audience (aud) claim is required only when sasl.oauthbearer.expected.audience is set. When it is unset, a validly-signed token that omits the aud claim is accepted. (A token that carries an aud claim is still rejected when no expected audience is configured.) Both options default to unset and have been documented as optional (Importance LOW) since KIP-768 (3.1.0). Impact: The exposure is realizable mainly in deployments whose JWKS endpoint serves signing keys for more than one issuer (a multi-tenant identity provider, an aggregated/shared JWKS, or shared signing keys): a token minted for a different issuer, or a token lacking an audience, may be accepted to authenticate — potentially as a higher-privileged principal. In a single-issuer deployment where the provider controls the iss claim and issues audience-scoped tokens, exposure is limited. The signature trust anchor remains enforced in all cases. This is distinct from CVE-2026-33557 (acceptance of unsigned/unvalidated tokens); here the signature is validated and only the issuer/audience checks are not enforced by default. Mitigation (all affected versions, no upgrade required): Set both sasl.oauthbearer.expected.issuer (to your provider's exact iss value) and sasl.oauthbearer.expected.audience (to the audience(s) your brokers expect), per listener. Brokers that set these perform exact-match issuer/audience checks and are not affected. Both have been available since 3.1.0. Resolution: - From Apache Kafka 4.4.0: a broker configured with a JWKS endpoint fails to start unless both sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience are set (secure by default). Deployments that intentionally do not restrict the issuer and/or audience may opt out per axis with sasl.oauthbearer.allow.unverified.issuer=true and/or sasl.oauthbearer.allow.unverified.audience=true.10h CVE-2026-1166728.8 HIG

—

——0Authlib is a Python library which builds OAuth and OpenID Connect servers. From 0.15 until 1.9.1, the documented ClientConfigurationEndpoint.authenticate_client and ClientConfigurationEndpoint.check_permission reference implementations look up a target client from request-controlled client_id data and check only whether that target is editable, without verifying that request.credential belongs to the target client. Deployments following both examples can allow a client holding any valid registration access token to read, modify, or delete another client's registration. Changing redirect_uris can enable authorization code or token interception, while deleting registrations can deny service to affected clients. This issue is fixed in version 1.9.1.1d CVE-2026-257849.8 CRI

27.9%

——8Initialization of a Resource with an Insecure Default vulnerability in Hallo Welt! GmbH BlueSpice (container image bluespice/wiki) allows privilege escalation. The default value of $mwsgTokenAuthenticatorServiceCIDR in the container's LocalSettings.php was intended to restrict internal service authentication to the container network, but evaluated to an empty string when the environment variable WIKI_SERVICE_TOKEN_AUTH_ALLOWED was not set. An empty value disables the IP restriction in the token authenticator component (mwstake/mediawiki-component-token-authenticator). As a result, any user with read access to the wiki (anonymous users on publicly readable wikis) could obtain an application token from the REST API and use it to get a session with sysop privileges as the internal service user. This issue affects BlueSpice: from 5.2.3 before 5.2.7, and the 5.2.7 container images published before 2026-10-19 15:37 UTC.5d CVE-2026-1146186.8 MED

13.1%

——4Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.9.0, the default RFC 7523 JWTBearerGrant.get_audiences() returns an empty list, causing JWTBearerGrant.verify_claims() to require only that an aud claim exists without matching the current authorization server. An attacker holding a legitimate assertion for another service can present it to a server that shares the signing key and uses the default grant, obtaining an access token across a trust boundary. Implementations that override get_audiences() with the server's valid audience identifiers are not affected. This issue is fixed in version 1.9.0.5d CVE-2026-1141237.5 HIG

36.4%

——11D365 F&O MCP Server is a Model Context Protocol server for querying Dynamics 365 Finance & Operations X++ code and metadata. Prior to version 1.11.0, the officially documented Azure one-click deployment uses infrastructure/azuredeploy.json and infrastructure/main.bicep to default the apiKey parameter to an empty string and pass it to the App Service API_KEY setting. With API_KEY unset or empty, src/middleware/apiKeyAuth.ts passes requests through without authentication, while src/index.ts binds the HTTP listener to 0.0.0.0 by default. If the deployer leaves the optional key blank and does not add separate network restrictions or upstream authentication, the resulting public App Service allows unauthenticated JSON-RPC tools/call requests to /mcp. The deployment's MCP_SERVER_MODE=read-only setting does not prevent anonymous access to read/search tools, including search, get_object_info, batch_get_info, extension_info, security_info, find_references, and find_event_handlers, exposing indexed proprietary X++ source snippets and metadata. Exposed information can include business logic, extension and event-handler wiring, security-role and privilege structure, and labels originally indexed from PackagesLocalDirectory. Deployments protected by a configured API key, effective upstream authentication, or network restrictions preventing attacker access are outside this unauthenticated exposure scenario. This issue is fixed in version 1.11.0.7d