CVE Watch29 oct 2026

CVE-2026-112255

Initialization of a resource with an insecure default vulnerability in OpenText Advanced Authentication Server allows Excessive Allocation.

CVSS

—

Sin CVSS

EPSS

—

KEV

—

Exploit Today

—

0-100

Publicado: 29 oct 2026 · Última mod.: 29 oct 2026 · CWE-1188

EPSS · 30d

Sin historial EPSS suficiente todavía.

Descripción técnica

Initialization of a resource with an insecure default vulnerability in OpenText Advanced Authentication Server allows Excessive Allocation. This issue affects Advanced Authentication Server: from 6.4.0.0 through 6.4.3.x, from 6.5.0.0 through 6.5.0.x, and from 6.6.0.0 through 6.6.1.0. The fix for this is issue is to create a secure configuration. The 6.6.2.0 release has a best practice entry if the configuration is unsecure. A secure configuration is to NOT allow creation/recreation of Unauthenticated Endpoints. If creation/recreation of Unauthenticated Endpoints is required, you should only allow it from trusted networks. To remedy this issue, change your configuration to NOT allow creation/recreation of Unauthenticated Endpoints. If you require Unauthenticated Endpoints, you MUST change your configuration to use a non-empty whitelist to specify the trusted networks. An empty whitelist will allow all networks to create/recreate endpoints.

Referencias oficiales

CVEs relacionados

CVECVSSEPSSKEVRExplotTítuloVis.

CVE-2026-1186913.7 BAJ

—

——0xianyu-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.6h CVE-2026-116273—

—

——0MIME::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.7h CVE-2026-110952—

—

——0A 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.7h CVE-2026-1166728.8 ALT

19.8%

——6Authlib 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.2d CVE-2026-257849.8 CRÍ

28.0%

——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.6d CVE-2026-1146186.8 MED

13.2%

——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.7h