CVE-2026-78551 (GCVE-0-2026-78551)
Vulnerability from cvelistv5 – Published: 2026-08-24 19:20 – Updated: 2026-08-24 20:07
VLAI
EPSS
VEX
Title
RansomLook Login Endpoint Allows Timing-Based Username Enumeration and Unthrottled Authentication Attempts
Summary
RansomLook contains multiple weaknesses in its authentication endpoint that allow an unauthenticated remote attacker to enumerate valid usernames, perform unrestricted password-guessing attacks, and potentially exhaust application worker resources.
For local authentication, the login implementation previously checked whether a submitted username existed before invoking the password hash verification function. Requests containing a nonexistent username therefore returned significantly faster than requests for valid accounts, for which the computationally expensive password verification routine was executed. A remote attacker could measure these response-time differences to determine which usernames correspond to valid RansomLook accounts.
In addition, the /login endpoint did not restrict the number or frequency of failed authentication attempts. An attacker could consequently perform password brute-force, dictionary, password-spraying, or credential-stuffing attacks against known accounts without server-side throttling. For valid usernames, each authentication attempt also invokes the password key-derivation function, which consumes a significant amount of CPU time. A sufficiently high rate of login attempts could therefore occupy the application's synchronous Gunicorn workers and cause a denial of service affecting the entire application.
The issue has been addressed by always performing password verification using a randomly generated dummy password hash when the supplied username does not exist, eliminating the username-dependent timing discrepancy. Failed authentication attempts are additionally rate-limited per client IP address using Valkey/Redis, with five failed attempts within five minutes resulting in a one-hour block. The reverse-proxy configuration was also updated so that the application derives the client address from a trusted X-Forwarded-For value that cannot be overridden by a client-supplied header.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-24 20:07 UTC
CWE
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/RansomLook/RansomLook/commit/8… | patch |
Impacted products
1 product
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| ransomlook | ransomlook |
Affected:
0 , ≤ 2.0.0
(semver)
|
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-78551",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-24T20:07:33.863606Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-24T20:07:41.242Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "ransomlook",
"vendor": "ransomlook",
"versions": [
{
"lessThanOrEqual": "2.0.0",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Jeroen Pinoy"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Fafner [_KeyZee_]"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eRansomLook contains multiple weaknesses in its authentication endpoint that allow an unauthenticated remote attacker to enumerate valid usernames, perform unrestricted password-guessing attacks, and potentially exhaust application worker resources.\u003c/p\u003e\u003cp\u003eFor local authentication, the login implementation previously checked whether a submitted username existed before invoking the password hash verification function. Requests containing a nonexistent username therefore returned significantly faster than requests for valid accounts, for which the computationally expensive password verification routine was executed. A remote attacker could measure these response-time differences to determine which usernames correspond to valid RansomLook accounts.\u003c/p\u003e\u003cp\u003eIn addition, the \u003ccode\u003e/login\u003c/code\u003e endpoint did not restrict the number or frequency of failed authentication attempts. An attacker could consequently perform password brute-force, dictionary, password-spraying, or credential-stuffing attacks against known accounts without server-side throttling. For valid usernames, each authentication attempt also invokes the password key-derivation function, which consumes a significant amount of CPU time. A sufficiently high rate of login attempts could therefore occupy the application\u0027s synchronous Gunicorn workers and cause a denial of service affecting the entire application.\u003c/p\u003e\u003cp\u003eThe issue has been addressed by always performing password verification using a randomly generated dummy password hash when the supplied username does not exist, eliminating the username-dependent timing discrepancy. Failed authentication attempts are additionally rate-limited per client IP address using Valkey/Redis, with five failed attempts within five minutes resulting in a one-hour block. The reverse-proxy configuration was also updated so that the application derives the client address from a trusted \u003ccode\u003eX-Forwarded-For\u003c/code\u003e value that cannot be overridden by a client-supplied header.\u003c/p\u003e\u003cbr\u003e"
}
],
"value": "RansomLook contains multiple weaknesses in its authentication endpoint that allow an unauthenticated remote attacker to enumerate valid usernames, perform unrestricted password-guessing attacks, and potentially exhaust application worker resources.\n\nFor local authentication, the login implementation previously checked whether a submitted username existed before invoking the password hash verification function. Requests containing a nonexistent username therefore returned significantly faster than requests for valid accounts, for which the computationally expensive password verification routine was executed. A remote attacker could measure these response-time differences to determine which usernames correspond to valid RansomLook accounts.\n\nIn addition, the /login endpoint did not restrict the number or frequency of failed authentication attempts. An attacker could consequently perform password brute-force, dictionary, password-spraying, or credential-stuffing attacks against known accounts without server-side throttling. For valid usernames, each authentication attempt also invokes the password key-derivation function, which consumes a significant amount of CPU time. A sufficiently high rate of login attempts could therefore occupy the application\u0027s synchronous Gunicorn workers and cause a denial of service affecting the entire application.\n\nThe issue has been addressed by always performing password verification using a randomly generated dummy password hash when the supplied username does not exist, eliminating the username-dependent timing discrepancy. Failed authentication attempts are additionally rate-limited per client IP address using Valkey/Redis, with five failed attempts within five minutes resulting in a one-hour block. The reverse-proxy configuration was also updated so that the application derives the client address from a trusted X-Forwarded-For value that cannot be overridden by a client-supplied header."
}
],
"impacts": [
{
"capecId": "CAPEC-49",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-49 Password Brute Forcing"
}
]
},
{
"capecId": "CAPEC-16",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-16 Dictionary-based Password Attack"
}
]
},
{
"capecId": "CAPEC-565",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-565 Password Spraying"
}
]
},
{
"capecId": "CAPEC-600",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-600 Credential Stuffing"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-307",
"description": "CWE-307 Improper Restriction of Excessive Authentication Attempts",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-400",
"description": "CWE-400 Uncontrolled Resource Consumption",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-24T19:20:03.145Z",
"orgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"shortName": "CIRCL"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/RansomLook/RansomLook/commit/8602740347b0e928ad9fbaf5bc6ff242337dec6b"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "RansomLook Login Endpoint Allows Timing-Based Username Enumeration and Unthrottled Authentication Attempts",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"assignerShortName": "CIRCL",
"cveId": "CVE-2026-78551",
"datePublished": "2026-08-24T19:20:03.145Z",
"dateReserved": "2026-08-24T19:19:59.060Z",
"dateUpdated": "2026-08-24T20:07:41.242Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-78551",
"date": "2026-10-21",
"epss": "0.00649",
"percentile": "0.50412"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "ransomlook",
"vendor": "ransomlook",
"versions": [
{
"lessThanOrEqual": "2.0.0",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"source": "5a6e4751-2f3f-4070-9419-94fb35b644e8"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "RansomLook contains multiple weaknesses in its authentication endpoint that allow an unauthenticated remote attacker to enumerate valid usernames, perform unrestricted password-guessing attacks, and potentially exhaust application worker resources.\n\nFor local authentication, the login implementation previously checked whether a submitted username existed before invoking the password hash verification function. Requests containing a nonexistent username therefore returned significantly faster than requests for valid accounts, for which the computationally expensive password verification routine was executed. A remote attacker could measure these response-time differences to determine which usernames correspond to valid RansomLook accounts.\n\nIn addition, the /login endpoint did not restrict the number or frequency of failed authentication attempts. An attacker could consequently perform password brute-force, dictionary, password-spraying, or credential-stuffing attacks against known accounts without server-side throttling. For valid usernames, each authentication attempt also invokes the password key-derivation function, which consumes a significant amount of CPU time. A sufficiently high rate of login attempts could therefore occupy the application\u0027s synchronous Gunicorn workers and cause a denial of service affecting the entire application.\n\nThe issue has been addressed by always performing password verification using a randomly generated dummy password hash when the supplied username does not exist, eliminating the username-dependent timing discrepancy. Failed authentication attempts are additionally rate-limited per client IP address using Valkey/Redis, with five failed attempts within five minutes resulting in a one-hour block. The reverse-proxy configuration was also updated so that the application derives the client address from a trusted X-Forwarded-For value that cannot be overridden by a client-supplied header."
},
{
"lang": "es",
"value": "RansomLook contiene m\u00faltiples debilidades en su punto final de autenticaci\u00f3n que permiten a un atacante remoto no autenticado enumerar nombres de usuario v\u00e1lidos, realizar ataques de adivinaci\u00f3n de contrase\u00f1as sin restricciones y potencialmente agotar los recursos de los trabajadores de la aplicaci\u00f3n.\n\nPara la autenticaci\u00f3n local, la implementaci\u00f3n de inicio de sesi\u00f3n verificaba previamente si un nombre de usuario enviado exist\u00eda antes de invocar la funci\u00f3n de verificaci\u00f3n del hash de la contrase\u00f1a. Las solicitudes que conten\u00edan un nombre de usuario inexistente, por lo tanto, regresaban significativamente m\u00e1s r\u00e1pido que las solicitudes para cuentas v\u00e1lidas, para las cuales se ejecutaba la rutina de verificaci\u00f3n de contrase\u00f1a computacionalmente costosa. Un atacante remoto podr\u00eda medir estas diferencias en el tiempo de respuesta para determinar qu\u00e9 nombres de usuario corresponden a cuentas v\u00e1lidas de RansomLook.\n\nAdem\u00e1s, el punto final /login no restring\u00eda el n\u00famero o la frecuencia de los intentos de autenticaci\u00f3n fallidos. Un atacante podr\u00eda, en consecuencia, realizar ataques de fuerza bruta de contrase\u00f1as, de diccionario, de pulverizaci\u00f3n de contrase\u00f1as o de relleno de credenciales contra cuentas conocidas sin limitaci\u00f3n por parte del servidor. Para nombres de usuario v\u00e1lidos, cada intento de autenticaci\u00f3n tambi\u00e9n invoca la funci\u00f3n de derivaci\u00f3n de clave de contrase\u00f1a, que consume una cantidad significativa de tiempo de CPU. Una tasa suficientemente alta de intentos de inicio de sesi\u00f3n podr\u00eda, por lo tanto, ocupar los trabajadores s\u00edncronos de Gunicorn de la aplicaci\u00f3n y causar una denegaci\u00f3n de servicio que afecte a toda la aplicaci\u00f3n.\n\nEl problema se ha abordado realizando siempre la verificaci\u00f3n de la contrase\u00f1a utilizando un hash de contrase\u00f1a ficticio generado aleatoriamente cuando el nombre de usuario proporcionado no existe, eliminando la discrepancia de tiempo dependiente del nombre de usuario. Los intentos de autenticaci\u00f3n fallidos est\u00e1n adicionalmente limitados por tasa por direcci\u00f3n IP del cliente utilizando Valkey/Redis, con cinco intentos fallidos en cinco minutos resultando en un bloqueo de una hora. La configuraci\u00f3n del proxy inverso tambi\u00e9n se actualiz\u00f3 para que la aplicaci\u00f3n derive la direcci\u00f3n del cliente de un valor X-Forwarded-For de confianza que no puede ser anulado por un encabezado proporcionado por el cliente."
}
],
"id": "CVE-2026-78551",
"lastModified": "2026-10-12T21:10:00.227",
"metrics": {
"cvssMetricV40": [
{
"cvssData": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"availabilityRequirement": "NOT_DEFINED",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"confidentialityRequirement": "NOT_DEFINED",
"exploitMaturity": "NOT_DEFINED",
"integrityRequirement": "NOT_DEFINED",
"modifiedAttackComplexity": "NOT_DEFINED",
"modifiedAttackRequirements": "NOT_DEFINED",
"modifiedAttackVector": "NOT_DEFINED",
"modifiedPrivilegesRequired": "NOT_DEFINED",
"modifiedSubAvailabilityImpact": "NOT_DEFINED",
"modifiedSubConfidentialityImpact": "NOT_DEFINED",
"modifiedSubIntegrityImpact": "NOT_DEFINED",
"modifiedUserInteraction": "NOT_DEFINED",
"modifiedVulnAvailabilityImpact": "NOT_DEFINED",
"modifiedVulnConfidentialityImpact": "NOT_DEFINED",
"modifiedVulnIntegrityImpact": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:H/SC:N/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:X",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"source": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-78551",
"options": [
{
"exploitation": "none"
},
{
"automatable": "yes"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-24T20:07:33.863606Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-08-24T20:17:23.927",
"references": [
{
"source": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"url": "https://github.com/RansomLook/RansomLook/commit/8602740347b0e928ad9fbaf5bc6ff242337dec6b"
}
],
"sourceIdentifier": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"vulnStatus": "Deferred",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-307"
},
{
"lang": "en",
"value": "CWE-400"
}
],
"source": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"type": "Secondary"
}
]
}
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-78551",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-24T20:07:33.863606Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-24T20:07:38.280Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "ransomlook",
"vendor": "ransomlook",
"versions": [
{
"lessThanOrEqual": "2.0.0",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Jeroen Pinoy"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Fafner [_KeyZee_]"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eRansomLook contains multiple weaknesses in its authentication endpoint that allow an unauthenticated remote attacker to enumerate valid usernames, perform unrestricted password-guessing attacks, and potentially exhaust application worker resources.\u003c/p\u003e\u003cp\u003eFor local authentication, the login implementation previously checked whether a submitted username existed before invoking the password hash verification function. Requests containing a nonexistent username therefore returned significantly faster than requests for valid accounts, for which the computationally expensive password verification routine was executed. A remote attacker could measure these response-time differences to determine which usernames correspond to valid RansomLook accounts.\u003c/p\u003e\u003cp\u003eIn addition, the \u003ccode\u003e/login\u003c/code\u003e endpoint did not restrict the number or frequency of failed authentication attempts. An attacker could consequently perform password brute-force, dictionary, password-spraying, or credential-stuffing attacks against known accounts without server-side throttling. For valid usernames, each authentication attempt also invokes the password key-derivation function, which consumes a significant amount of CPU time. A sufficiently high rate of login attempts could therefore occupy the application\u0027s synchronous Gunicorn workers and cause a denial of service affecting the entire application.\u003c/p\u003e\u003cp\u003eThe issue has been addressed by always performing password verification using a randomly generated dummy password hash when the supplied username does not exist, eliminating the username-dependent timing discrepancy. Failed authentication attempts are additionally rate-limited per client IP address using Valkey/Redis, with five failed attempts within five minutes resulting in a one-hour block. The reverse-proxy configuration was also updated so that the application derives the client address from a trusted \u003ccode\u003eX-Forwarded-For\u003c/code\u003e value that cannot be overridden by a client-supplied header.\u003c/p\u003e\u003cbr\u003e"
}
],
"value": "RansomLook contains multiple weaknesses in its authentication endpoint that allow an unauthenticated remote attacker to enumerate valid usernames, perform unrestricted password-guessing attacks, and potentially exhaust application worker resources.\n\nFor local authentication, the login implementation previously checked whether a submitted username existed before invoking the password hash verification function. Requests containing a nonexistent username therefore returned significantly faster than requests for valid accounts, for which the computationally expensive password verification routine was executed. A remote attacker could measure these response-time differences to determine which usernames correspond to valid RansomLook accounts.\n\nIn addition, the /login endpoint did not restrict the number or frequency of failed authentication attempts. An attacker could consequently perform password brute-force, dictionary, password-spraying, or credential-stuffing attacks against known accounts without server-side throttling. For valid usernames, each authentication attempt also invokes the password key-derivation function, which consumes a significant amount of CPU time. A sufficiently high rate of login attempts could therefore occupy the application\u0027s synchronous Gunicorn workers and cause a denial of service affecting the entire application.\n\nThe issue has been addressed by always performing password verification using a randomly generated dummy password hash when the supplied username does not exist, eliminating the username-dependent timing discrepancy. Failed authentication attempts are additionally rate-limited per client IP address using Valkey/Redis, with five failed attempts within five minutes resulting in a one-hour block. The reverse-proxy configuration was also updated so that the application derives the client address from a trusted X-Forwarded-For value that cannot be overridden by a client-supplied header."
}
],
"impacts": [
{
"capecId": "CAPEC-49",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-49 Password Brute Forcing"
}
]
},
{
"capecId": "CAPEC-16",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-16 Dictionary-based Password Attack"
}
]
},
{
"capecId": "CAPEC-565",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-565 Password Spraying"
}
]
},
{
"capecId": "CAPEC-600",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-600 Credential Stuffing"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-307",
"description": "CWE-307 Improper Restriction of Excessive Authentication Attempts",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-400",
"description": "CWE-400 Uncontrolled Resource Consumption",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-24T19:20:03.145Z",
"orgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"shortName": "CIRCL"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/RansomLook/RansomLook/commit/8602740347b0e928ad9fbaf5bc6ff242337dec6b"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "RansomLook Login Endpoint Allows Timing-Based Username Enumeration and Unthrottled Authentication Attempts",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"assignerShortName": "CIRCL",
"cveId": "CVE-2026-78551",
"datePublished": "2026-08-24T19:20:03.145Z",
"dateReserved": "2026-08-24T19:19:59.060Z",
"dateUpdated": "2026-08-24T20:07:41.242Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.