CVE-2025-4143

{"id": "CVE-2025-4143", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "CHANGED", "version": "3.1", "baseScore": 6.1, "attackVector": "NETWORK", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N", "integrityImpact": "LOW", "userInteraction": "REQUIRED", "attackComplexity": "LOW", "availabilityImpact": "NONE", "privilegesRequired": "NONE", "confidentialityImpact": "LOW"}, "impactScore": 2.7, "exploitabilityScore": 2.8}], "cvssMetricV40": [{"type": "Secondary", "source": "cna@cloudflare.com", "cvssData": {"Safety": "NOT_DEFINED", "version": "4.0", "Recovery": "NOT_DEFINED", "baseScore": 6.0, "Automatable": "NOT_DEFINED", "attackVector": "NETWORK", "baseSeverity": "MEDIUM", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber", "exploitMaturity": "NOT_DEFINED", "providerUrgency": "AMBER", "userInteraction": "PASSIVE", "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "privilegesRequired": "NONE", "subIntegrityImpact": "NONE", "vulnIntegrityImpact": "NONE", "integrityRequirement": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "vulnAvailabilityImpact": "NONE", "availabilityRequirement": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "subConfidentialityImpact": "LOW", "vulnConfidentialityImpact": "HIGH", "confidentialityRequirement": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "vulnerabilityResponseEffort": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED"}}]}, "published": "2025-05-01T01:15:54.127", "references": [{"url": "https://github.com/cloudflare/workers-oauth-provider/pull/26", "tags": ["Issue Tracking", "Patch"], "source": "cna@cloudflare.com"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Secondary", "source": "cna@cloudflare.com", "description": [{"lang": "en", "value": "CWE-601"}]}, {"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-601"}]}], "descriptions": [{"lang": "en", "value": "The OAuth implementation in workers-oauth-provider that is part of MCP framework https://github.com/cloudflare/workers-mcp , did not correctly validate that redirect_uri was on the allowed list of redirect URIs for the given client registration.\n\nFixed in:\u00a0 https://github.com/cloudflare/workers-oauth-provider/pull/26 https://github.com/cloudflare/workers-oauth-provider/pull/26 \n\nImpact:\n\n \n\nUnder certain circumstances (see below), if a victim had previously authorized with a server built on workers-oath-provider, and an attacker could later trick the victim into visiting a malicious web site, then attacker could potentially steal the victim's credentials to the same OAuth server and subsequently impersonate them.\n\nIn order for the attack to be possible, the OAuth server's authorized callback must be designed to auto-approve authorizations that appear to come from an OAuth client that the victim has authorized previously. The authorization flow is not implemented by workers-oauth-provider; it is up to the application built on top to decide whether to implement such automatic re-authorization. However, many applications do implement such logic.\n\nNote: It is a basic, well-known requirement that OAuth servers should verify that the redirect URI is among the allowed list for the client, both during the authorization flow and subsequently when exchanging the authorization code for an access token. workers-oauth-provider implemented only the latter check, not the former. Unfortunately, the former is the much more important check.\u00a0Readers who are familiar with OAuth may recognize that failing to check redirect URIs against the allowed list is a well-known, basic mistake, covered extensively in the RFC and elsewhere. The author of this library would like everyone to know that he was, in fact, well-aware of this requirement, thought about it a lot while designing the library, and then, somehow, forgot to actually make sure the check was in the code. That is, it's not that he didn't know what he was doing, it's that he knew what he was doing but flubbed it."}, {"lang": "es", "value": "La implementaci\u00f3n de OAuth en workers-oauth-provider que forma parte del framework MCP https://github.com/cloudflare/workers-mcp , no valid\u00f3 correctamente que redirect_uri estuviera en la lista permitida de URI de redirecci\u00f3n para el registro de cliente dado. Corregido en: https://github.com/cloudflare/workers-oauth-provider/pull/26 https://github.com/cloudflare/workers-oauth-provider/pull/26 Impacto: Bajo ciertas circunstancias (ver abajo), si una v\u00edctima hab\u00eda autorizado previamente con un servidor construido sobre workers-oath-provider, y un atacante pudiera enga\u00f1ar posteriormente a la v\u00edctima para que visitara un sitio web malicioso, entonces el atacante podr\u00eda potencialmente robar las credenciales de la v\u00edctima al mismo servidor OAuth y posteriormente suplantarlas. Para que el ataque sea posible, la devoluci\u00f3n de llamada autorizada del servidor OAuth debe estar dise\u00f1ada para aprobar autom\u00e1ticamente las autorizaciones que parecen provenir de un cliente OAuth que la v\u00edctima ha autorizado previamente. El flujo de autorizaci\u00f3n no lo implementa workers-oauth-provider; la aplicaci\u00f3n subyacente decide si implementa o no dicha reautorizaci\u00f3n autom\u00e1tica. Sin embargo, muchas aplicaciones s\u00ed implementan esta l\u00f3gica. Nota: Es un requisito b\u00e1sico y bien conocido que los servidores OAuth verifiquen que la URI de redirecci\u00f3n se encuentre en la lista de permitidos para el cliente, tanto durante el flujo de autorizaci\u00f3n como posteriormente al intercambiar el c\u00f3digo de autorizaci\u00f3n por un token de acceso. workers-oauth-provider implement\u00f3 solo esta \u00faltima comprobaci\u00f3n, no la primera. Desafortunadamente, la primera es mucho m\u00e1s importante. Los lectores familiarizados con OAuth reconocer\u00e1n que no comprobar las URI de redirecci\u00f3n con la lista de permitidos es un error b\u00e1sico y bien conocido, ampliamente tratado en el RFC y en otras fuentes. El autor de esta librer\u00eda desea que todos sepan que, de hecho, conoc\u00eda bien este requisito, lo consider\u00f3 detenidamente durante su dise\u00f1o y, por alguna raz\u00f3n, olvid\u00f3 asegurarse de que la comprobaci\u00f3n estuviera incluida en el c\u00f3digo. Es decir, no es que no supiera lo que hac\u00eda, es que sab\u00eda lo que hac\u00eda pero lo hizo mal."}], "lastModified": "2025-05-12T19:39:43.820", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:a:cloudflare:workers-oauth-provider:0.0.5:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "9B01663B-708A-4C77-9347-EA3AC30A5C94"}], "operator": "OR"}]}], "sourceIdentifier": "cna@cloudflare.com"}