CVE-2025-24806 (GCVE-0-2025-24806)
Vulnerability from cvelistv5
Published
2025-02-19 17:19
Modified
2025-02-19 18:39
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-307 - Improper Restriction of Excessive Authentication Attempts
Summary
Authelia is an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for applications via a web portal. If users are allowed to sign in via both username and email the regulation system treats these as separate login events. This leads to the regulation limitations being effectively doubled assuming an attacker using brute-force to find a user password. It's important to note that due to the effective operation of regulation where no user-facing sign of their regulation ban being visible either via timing or via API responses, it's effectively impossible to determine if a failure occurs due to a bad username password combination, or a effective ban blocking the attempt which heavily mitigates any form of brute-force. This occurs because the records and counting process for this system uses the method utilized for sign in rather than the effective username attribute. This has a minimal impact on account security, this impact is increased naturally in scenarios when there is no two-factor authentication required and weak passwords are used. This makes it a bit easier to brute-force a password. A patch for this issue has been applied to versions 4.38.19, and 4.39.0. Users are advised to upgrade. Users unable to upgrade should 1. Not heavily modify the default settings in a way that ends up with shorter or less frequent regulation bans. The default settings effectively mitigate any potential for this issue to be exploited. and 2. Disable the ability for users to login via an email address.
References
{ "containers": { "adp": [ { "metrics": [ { "other": { "content": { "id": "CVE-2025-24806", "options": [ { "Exploitation": "none" }, { "Automatable": "no" }, { "Technical Impact": "partial" } ], "role": "CISA Coordinator", "timestamp": "2025-02-19T18:39:03.612465Z", "version": "2.0.3" }, "type": "ssvc" } } ], "providerMetadata": { "dateUpdated": "2025-02-19T18:39:15.855Z", "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP" }, "title": "CISA ADP Vulnrichment" } ], "cna": { "affected": [ { "product": "authelia", "vendor": "authelia", "versions": [ { "status": "affected", "version": "\u003c 4.38.19" } ] } ], "descriptions": [ { "lang": "en", "value": "Authelia is an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for applications via a web portal. If users are allowed to sign in via both username and email the regulation system treats these as separate login events. This leads to the regulation limitations being effectively doubled assuming an attacker using brute-force to find a user password. It\u0027s important to note that due to the effective operation of regulation where no user-facing sign of their regulation ban being visible either via timing or via API responses, it\u0027s effectively impossible to determine if a failure occurs due to a bad username password combination, or a effective ban blocking the attempt which heavily mitigates any form of brute-force. This occurs because the records and counting process for this system uses the method utilized for sign in rather than the effective username attribute. This has a minimal impact on account security, this impact is increased naturally in scenarios when there is no two-factor authentication required and weak passwords are used. This makes it a bit easier to brute-force a password. A patch for this issue has been applied to versions 4.38.19, and 4.39.0. Users are advised to upgrade. Users unable to upgrade should 1. Not heavily modify the default settings in a way that ends up with shorter or less frequent regulation bans. The default settings effectively mitigate any potential for this issue to be exploited. and 2. Disable the ability for users to login via an email address." } ], "metrics": [ { "cvssV4_0": { "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "attackVector": "NETWORK", "baseScore": 2.3, "baseSeverity": "LOW", "privilegesRequired": "LOW", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "NONE", "userInteraction": "NONE", "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "NONE", "vulnIntegrityImpact": "LOW" } } ], "problemTypes": [ { "descriptions": [ { "cweId": "CWE-307", "description": "CWE-307: Improper Restriction of Excessive Authentication Attempts", "lang": "en", "type": "CWE" } ] } ], "providerMetadata": { "dateUpdated": "2025-02-19T17:19:30.909Z", "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "shortName": "GitHub_M" }, "references": [ { "name": "https://github.com/authelia/authelia/security/advisories/GHSA-m5mf-3963-4x26", "tags": [ "x_refsource_CONFIRM" ], "url": "https://github.com/authelia/authelia/security/advisories/GHSA-m5mf-3963-4x26" }, { "name": "https://github.com/authelia/authelia/commit/d4a54189aa6563912f9427b96dcb01eacafa785c", "tags": [ "x_refsource_MISC" ], "url": "https://github.com/authelia/authelia/commit/d4a54189aa6563912f9427b96dcb01eacafa785c" } ], "source": { "advisory": "GHSA-m5mf-3963-4x26", "discovery": "UNKNOWN" }, "title": "Regulation applies separately to Username-based logins to Email-based logins in authelia" } }, "cveMetadata": { "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "assignerShortName": "GitHub_M", "cveId": "CVE-2025-24806", "datePublished": "2025-02-19T17:19:30.909Z", "dateReserved": "2025-01-23T17:11:35.840Z", "dateUpdated": "2025-02-19T18:39:15.855Z", "state": "PUBLISHED" }, "dataType": "CVE_RECORD", "dataVersion": "5.1", "vulnerability-lookup:meta": { "nvd": "{\"cve\":{\"id\":\"CVE-2025-24806\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2025-02-19T18:15:24.467\",\"lastModified\":\"2025-02-19T18:15:24.467\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"Authelia is an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for applications via a web portal. If users are allowed to sign in via both username and email the regulation system treats these as separate login events. This leads to the regulation limitations being effectively doubled assuming an attacker using brute-force to find a user password. It\u0027s important to note that due to the effective operation of regulation where no user-facing sign of their regulation ban being visible either via timing or via API responses, it\u0027s effectively impossible to determine if a failure occurs due to a bad username password combination, or a effective ban blocking the attempt which heavily mitigates any form of brute-force. This occurs because the records and counting process for this system uses the method utilized for sign in rather than the effective username attribute. This has a minimal impact on account security, this impact is increased naturally in scenarios when there is no two-factor authentication required and weak passwords are used. This makes it a bit easier to brute-force a password. A patch for this issue has been applied to versions 4.38.19, and 4.39.0. Users are advised to upgrade. Users unable to upgrade should 1. Not heavily modify the default settings in a way that ends up with shorter or less frequent regulation bans. The default settings effectively mitigate any potential for this issue to be exploited. and 2. Disable the ability for users to login via an email address.\"},{\"lang\":\"es\",\"value\":\"Authelia es un servidor de autenticaci\u00f3n y autorizaci\u00f3n de c\u00f3digo abierto que proporciona autenticaci\u00f3n de dos factores e inicio de sesi\u00f3n \u00fanico (SSO) para aplicaciones a trav\u00e9s de un portal web. Si se permite a los usuarios iniciar sesi\u00f3n tanto con nombre de usuario como con correo electr\u00f3nico, el sistema de regulaci\u00f3n los trata como eventos de inicio de sesi\u00f3n separados. Esto hace que las limitaciones de la regulaci\u00f3n se dupliquen en la pr\u00e1ctica, suponiendo que un atacante utilice la fuerza bruta para encontrar la contrase\u00f1a de un usuario. Es importante se\u00f1alar que, debido al funcionamiento eficaz de la regulaci\u00f3n, en el que no hay ninguna se\u00f1al visible para el usuario de su prohibici\u00f3n de regulaci\u00f3n, ya sea mediante el tiempo o mediante respuestas de API, es pr\u00e1cticamente imposible determinar si se produce una falla debido a una combinaci\u00f3n incorrecta de nombre de usuario y contrase\u00f1a, o una prohibici\u00f3n efectiva que bloquea el intento, lo que mitiga en gran medida cualquier forma de fuerza bruta. Esto ocurre porque el proceso de registros y recuento de este sistema utiliza el m\u00e9todo utilizado para iniciar sesi\u00f3n en lugar del atributo de nombre de usuario efectivo. Esto tiene un impacto m\u00ednimo en la seguridad de la cuenta; este impacto aumenta naturalmente en escenarios en los que no se requiere autenticaci\u00f3n de dos factores y se utilizan contrase\u00f1as d\u00e9biles. Esto hace que sea un poco m\u00e1s f\u00e1cil forzar una contrase\u00f1a. Se ha aplicado un parche para este problema a las versiones 4.38.19 y 4.39.0. Se recomienda a los usuarios que actualicen. Los usuarios que no puedan actualizar deben 1. No modificar en gran medida la configuraci\u00f3n predeterminada de una manera que termine con prohibiciones de regulaci\u00f3n m\u00e1s breves o menos frecuentes. La configuraci\u00f3n predeterminada mitiga de manera efectiva cualquier posibilidad de que se explote este problema. y 2. Deshabilitar la capacidad de los usuarios de iniciar sesi\u00f3n a trav\u00e9s de una direcci\u00f3n de correo electr\u00f3nico.\"}],\"metrics\":{\"cvssMetricV40\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"4.0\",\"vectorString\":\"CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/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\",\"baseScore\":2.3,\"baseSeverity\":\"LOW\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"HIGH\",\"attackRequirements\":\"PRESENT\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"vulnConfidentialityImpact\":\"NONE\",\"vulnIntegrityImpact\":\"LOW\",\"vulnAvailabilityImpact\":\"NONE\",\"subConfidentialityImpact\":\"NONE\",\"subIntegrityImpact\":\"NONE\",\"subAvailabilityImpact\":\"NONE\",\"exploitMaturity\":\"NOT_DEFINED\",\"confidentialityRequirement\":\"NOT_DEFINED\",\"integrityRequirement\":\"NOT_DEFINED\",\"availabilityRequirement\":\"NOT_DEFINED\",\"modifiedAttackVector\":\"NOT_DEFINED\",\"modifiedAttackComplexity\":\"NOT_DEFINED\",\"modifiedAttackRequirements\":\"NOT_DEFINED\",\"modifiedPrivilegesRequired\":\"NOT_DEFINED\",\"modifiedUserInteraction\":\"NOT_DEFINED\",\"modifiedVulnConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedVulnIntegrityImpact\":\"NOT_DEFINED\",\"modifiedVulnAvailabilityImpact\":\"NOT_DEFINED\",\"modifiedSubConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedSubIntegrityImpact\":\"NOT_DEFINED\",\"modifiedSubAvailabilityImpact\":\"NOT_DEFINED\",\"Safety\":\"NOT_DEFINED\",\"Automatable\":\"NOT_DEFINED\",\"Recovery\":\"NOT_DEFINED\",\"valueDensity\":\"NOT_DEFINED\",\"vulnerabilityResponseEffort\":\"NOT_DEFINED\",\"providerUrgency\":\"NOT_DEFINED\"}}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-307\"}]}],\"references\":[{\"url\":\"https://github.com/authelia/authelia/commit/d4a54189aa6563912f9427b96dcb01eacafa785c\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/authelia/authelia/security/advisories/GHSA-m5mf-3963-4x26\",\"source\":\"security-advisories@github.com\"}]}}", "vulnrichment": { "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2025-24806\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-02-19T18:39:03.612465Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-02-19T18:39:11.693Z\"}}], \"cna\": {\"title\": \"Regulation applies separately to Username-based logins to Email-based logins in authelia\", \"source\": {\"advisory\": \"GHSA-m5mf-3963-4x26\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV4_0\": {\"version\": \"4.0\", \"baseScore\": 2.3, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"LOW\", \"vectorString\": \"CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"HIGH\", \"attackRequirements\": \"PRESENT\", \"privilegesRequired\": \"LOW\", \"subIntegrityImpact\": \"NONE\", \"vulnIntegrityImpact\": \"LOW\", \"subAvailabilityImpact\": \"NONE\", \"vulnAvailabilityImpact\": \"NONE\", \"subConfidentialityImpact\": \"NONE\", \"vulnConfidentialityImpact\": \"NONE\"}}], \"affected\": [{\"vendor\": \"authelia\", \"product\": \"authelia\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 4.38.19\"}]}], \"references\": [{\"url\": \"https://github.com/authelia/authelia/security/advisories/GHSA-m5mf-3963-4x26\", \"name\": \"https://github.com/authelia/authelia/security/advisories/GHSA-m5mf-3963-4x26\", \"tags\": [\"x_refsource_CONFIRM\"]}, {\"url\": \"https://github.com/authelia/authelia/commit/d4a54189aa6563912f9427b96dcb01eacafa785c\", \"name\": \"https://github.com/authelia/authelia/commit/d4a54189aa6563912f9427b96dcb01eacafa785c\", \"tags\": [\"x_refsource_MISC\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"Authelia is an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for applications via a web portal. If users are allowed to sign in via both username and email the regulation system treats these as separate login events. This leads to the regulation limitations being effectively doubled assuming an attacker using brute-force to find a user password. It\u0027s important to note that due to the effective operation of regulation where no user-facing sign of their regulation ban being visible either via timing or via API responses, it\u0027s effectively impossible to determine if a failure occurs due to a bad username password combination, or a effective ban blocking the attempt which heavily mitigates any form of brute-force. This occurs because the records and counting process for this system uses the method utilized for sign in rather than the effective username attribute. This has a minimal impact on account security, this impact is increased naturally in scenarios when there is no two-factor authentication required and weak passwords are used. This makes it a bit easier to brute-force a password. A patch for this issue has been applied to versions 4.38.19, and 4.39.0. Users are advised to upgrade. Users unable to upgrade should 1. Not heavily modify the default settings in a way that ends up with shorter or less frequent regulation bans. The default settings effectively mitigate any potential for this issue to be exploited. and 2. Disable the ability for users to login via an email address.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-307\", \"description\": \"CWE-307: Improper Restriction of Excessive Authentication Attempts\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2025-02-19T17:19:30.909Z\"}}}", "cveMetadata": "{\"cveId\": \"CVE-2025-24806\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-02-19T18:39:15.855Z\", \"dateReserved\": \"2025-01-23T17:11:35.840Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2025-02-19T17:19:30.909Z\", \"assignerShortName\": \"GitHub_M\"}", "dataType": "CVE_RECORD", "dataVersion": "5.1" } } }
Loading…
Loading…
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…