Net::OAuth versions before 0.33 for Perl allow the sender to choose the signature algorithm in verify. verify resolves the signature…
CPANSec·CWE-347·Published 2026-08-19
Net::OAuth versions before 0.33 for Perl allow the sender to choose the signature algorithm in verify. verify resolves the signature method class from the signature_method parameter of the incoming message. signature_method is required on every request, so the algorithm used to check a signature is chosen by whoever sent it, and nothing lets the verifying party pin the method instead. When a message names HMAC-SHA1 or HMAC-SHA256, the key is derived from consumer_secret and token_secret rather than from the key the provider deployed. A provider deployed on RSA-SHA1 holds only the consumer public key, and RFC 5849 does not use consumer_secret for that method, so the required parameter is filled with a placeholder. A client that names HMAC-SHA1 instead has its signature checked against that placeholder, so a guessable one is enough to forge requests for any consumer key and token.
Net::OAuth versions before 0.33 for Perl allow the sender to choose the signature algorithm in verify. verify resolves the signature method class from the signature_method parameter of the incoming message. signature_method is required on every request, so the algorithm used to check a signature is chosen by whoever sent it, and nothing lets the verifying party pin the method instead. When a message names HMAC-SHA1 or HMAC-SHA256, the key is derived from consumer_secret and token_secret rather than from the key the provider deployed. A provider deployed on RSA-SHA1 holds only the consumer public key, and RFC 5849 does not use consumer_secret for that method, so the required parameter is filled with a placeholder. A client that names HMAC-SHA1 instead has its signature checked against that placeholder, so a guessable one is enough to forge requests for any consumer key and token.
Las versiones de Net::OAuth anteriores a la 0.33 para Perl permiten al remitente elegir el algoritmo de firma en verify. verify resuelve la clase del método de firma a partir del parámetro signature_method del mensaje entrante. signature_method es requerido en cada solicitud, por lo que el algoritmo utilizado para verificar una firma es elegido por quien la envió, y nada permite a la parte verificadora fijar el método en su lugar. Cuando un mensaje nombra HMAC-SHA1 o HMAC-SHA256, la clave se deriva de consumer_secret y token_secret en lugar de la clave que el proveedor implementó. Un proveedor implementado en RSA-SHA1 solo posee la clave pública del consumidor, y RFC 5849 no utiliza consumer_secret para ese método, por lo que el parámetro requerido se rellena con un marcador de posición. Un cliente que nombra HMAC-SHA1 en su lugar tiene su firma verificada contra ese marcador de posición, por lo que uno adivinable es suficiente para falsificar solicitudes para cualquier clave de consumidor y token.
| Version | Type | Source | Base | Exp | Impact | Vector |
|---|---|---|---|---|---|---|
| 3.1 | Primary | cve.org | 9.8 | — | — | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| 3.1 | Secondary | NVD | 9.8 | 3.9 | 5.9 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| 3.1 | Secondary | ENISA EUVD | 9.8 | — | — | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |