GCVE-1-2026-20086 (CVE-2026-78551)

Vulnerability from gna-1 – Published: 2026-08-24 19:19 – Updated: 2026-08-24 19:19
VLAI
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
8.8 (High)
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
CWE
  • CWE-307 - Improper Restriction of Excessive Authentication Attempts
  • CWE-400 - Uncontrolled Resource Consumption
Assigner
References
Impacted products
Vendor Product Version CPE status
ransomlook ransomlook Affected: 0 , ≤ 2.0.0 (semver)
guessed Create a notification for this product.
Credits
Jeroen Pinoy Fafner [_KeyZee_]
To clipboard 

{
  "containers": {
    "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": {
        "orgId": "00000000-0000-4000-9000-000000000000"
      },
      "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": "00000000-0000-4000-9000-000000000000",
    "cveId": "CVE-2026-78551",
    "datePublished": "2026-08-24T19:19:50.807894Z",
    "dateReserved": "2026-08-24T19:19:59.060Z",
    "dateUpdated": "2026-08-24T19:19:59.130934Z",
    "requesterUserId": "00000000-0000-4000-9000-000000000000",
    "serial": 1,
    "state": "PUBLISHED",
    "vulnId": "gcve-1-2026-20086"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





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.


Detection rules are retrieved from Rulezet.