CVE-2026-73535
Gitea's OpenID connect handler accepts a user's password without enforcing enrolled TOTP or WebAuthn verification before completing sign-in
CVSS
—
Sin CVSS
EPSS
—
KEV
—
Exploit Today
0
0-100
Publicado: 14 oct 2026 · Última mod.: 14 oct 2026 · CWE-304 · CWE-696
Sin historial EPSS suficiente todavía.
Gitea's OpenID connect handler accepts a user's password without enforcing enrolled TOTP or WebAuthn verification before completing sign-in and linking an OpenID identifier. When OpenID sign-in is enabled, an attacker who knows the victim's password can obtain a session and link an attacker-controlled identifier. The attacker can then sign in through that identifier without the victim's password or second factor, and a password change does not remove the link.
- blog.gitea.comhttps://blog.gitea.com/release-of-1.27.2/
- github.comhttps://github.com/go-gitea/gitea/pull/38805
- github.comhttps://github.com/go-gitea/gitea/pull/38810
- github.comhttps://github.com/go-gitea/gitea/releases/tag/v1.27.2
- github.comhttps://github.com/go-gitea/gitea/security/advisories/GHSA-8xjr-x7rg-hp5h
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-890688.1 ALT—
——0Missing critical step in authentication vulnerability in Progress MOVEit Transfer (LDAP module).
This issue affects MOVEit Transfer: before 2025.1.6 and from 2026.0.0 before 2026.0.4.8hCVE-2026-108071——
——0Incorrect authentication vulnerability in the TSplus Remote Access multi-factor authentication (MFA) mechanism. A remote attacker authenticated with valid first-factor credentials could bypass the second-factor verification because the authentication flow does not correctly apply the MFA validation result, allowing the attacker to complete the login without a valid second-factor token and gain access to protected applications and resources.1dCVE-2026-1104508.0 ALT3.8%
——1Nix before 2.35.3 and Lix before 2.95.4 allow privilege escalation via a repair operation because it could destroy and then replace a store path before content verification.2dCVE-2026-109162—41.8%
——13Forms using FileUpload or ImageUpload elements with a custom saveToFileMount configured stored uploaded files in the default storage folder 1:/user_upload/ instead of the configured destination. This could cause uploaded files to end up in a publicly accessible storage even though a restricted, non-public storage had been configured. Files stored this way are served directly, without the access checks applied to non-public storages. Forms that use the default value for saveToFileMount are not affected. This issue affects TYPO3 CMS versions 14.0.0-14.3.8.1dCVE-2026-262877.1 ALT14.5%
——4External Secrets Operator reads information from a third-party service and automatically injects the values as Kubernetes Secrets. Starting in version 0.10.0 and prior to version 1.3.2, a bug in the `webhook` generator initialization order incorrectly cleared the label-enforcement flag (`EnforceLabels`) after it was set, resulting in the provider-side check for `external-secrets.io/type=webhook` being skipped (and the operation to succeed while it should have failed with `secret does not contain needed label 'external-secrets.io/type: webhook'. Update secret label to use it with webhook`. Version 1.3.2 contains a patch.9dCVE-2026-1057456.7 MED1.7%
——1Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.27.0 until 2.131.0, Docling plugin factories in docling/models/factories/base_factory.py call load_setuptools_entrypoints() before applying the allow_external_plugins setting, so every module registered in the Docling entry-point group is imported even when external plugins are disabled. An installed third-party or compromised package can therefore execute import-time code when Docling starts, while the subsequent namespace filter misleadingly reports that the plugin was not loaded. This issue is fixed in 2.131.0.8d