2025-09 IncludeSec pentest
In September of 2025, we had a pentest conducted by Include Security. This resulted in a number of code improvements to our application, however did not result in any assigned CVEs.
IncludeSec performed a security assessment of Authentik Security's Web Apps, APIs, Deployment Config, Servers, & ETL. The assessment team performed a 8 day effort spanning from September 4 through September 15, 2025, using a Standard Grey Box assessment methodology.
View the full report of our original test and the retest results, completed in January/February 2026.
Summary of findings
Below is a table summarizing the findings from the report, along with IncludeSec's risk labeling and our contextual categorization of these risks. As IncludeSec states, "It is common and encouraged that all clients recategorize findings based on their internal business risk tolerances."
| Finding | IncludeSec Risk | Status | authentik Risk Categorization |
|---|---|---|---|
| H1 | High | Risk Accepted | Expected behavior |
| H2 | High | Closed | Low |
| H3 | High | Risk Accepted | Expected behavior |
| M1 | Medium | Fixed in 2025.12 | Low |
| M2 | Medium | Closed | Low |
| L1 | Low | Closed | Low |
| L2 | Low | Closed | Low |
| L3 | Low | Closed | None (not exploitable) |
| L4 | Low | Closed | Low |
During the time of this test, we also separately addressed a number of community-reported CVEs as reported in our security pages.
Responses to specific findings
This is the complete list of findings from the audit, with information about how we addressed each.
H1: Blueprint Import Allows Arbitrary Modification of Application Objects (Internal: None)
Issue: This is intended functionality. This behavior reflects the privileged design of blueprint imports. It is 'exploitable' when importing blueprints from untrusted sources without reviewing the blueprint beforehand. Flow imports are technically blueprint imports, which by design can be used to create any object within authentik.
Improvement: We added a warning banner with 2025.12 to flow imports.
H2: TOTP Brute-Force Vulnerability (Internal: Low) - Closed
Issue: TOTP could in theory be brute-forced for login given knowledge of a target user's password, enough time, and no WAF/altering on high amounts of requests.
Improvement: We added stricter rate limiting to the infrastructure used for testing.
In addition to using authentik's built-in methods to reduce the ability for attackers to brute-force credentials, we also recommend that customers use a WAF.
H3: Arbitrary Python Code execution (Internal: None)
Issue: The authentik application allowed execution of arbitrary Python code with the same privileges as the application's system user. This behavior extended to prompt stages.
Response: By design, prompt inputs can be configured to have placeholder values based on Python expressions, inheriting the behavior from expression policies. Our hardening docs already cover this topic.
M1: Anti-Brute Force Mechanisms Bypassed via Race conditions
Issue: The anti-brute force mechanism could be bypassed by triggering a race condition using the default-authentication-flow, given enough time and no WAF/other filtering in place.
Improvement: In 2025.12, we replaced session-based login attempt retries to rely instead on the reputation scores.
Once again, in addition to using authentik's built-in methods to reduce the ability for attackers to brute-force credentials, we recommend that customers use a WAF.
M2: Password Hashes Disclosed via Application Launch URL (Internal: Low) - Closed
Issue: authentik disclosed salted user password hashes to a privileged user when accessing a specially crafted launch URL for a custom Application.
Fix: We improved the Application launch URL format.
L1: FROM Tags in Dockerfiles Enable Supply-Chain Takeover (Internal: Low) - Closed
Issue: Our container build process used Dockerfiles containing unpinned tags, allowing a possible supply chain attack from an attacker with control of the referenced repository who could repoint the tag to a different image.
Fix: We updated to use image digests for Dockerfile FROM calls.
L2: User Accounts Enumerable
Issue: In the small test environment, the application's response time varied based on whether the supplied account was associated with a valid user, allowing potential account enumeration.
In real-world production environments with typical network latency and reverse proxies, the timing variance would likely be obscured.
Improvement: We replaced a randomized call to sleep with make_password, which better emulates checking the password of a user.
L3: [Server] Shell Command Execution Did Not Use Absolute Path (Internal: Low) - Closed
Issue: authentik called OpenSSL based on its binary name without specifying an absolute path, which could lead to path hijacking.
Fix: We updated the OpenSSL call to use the absolute binary path.
L4: [Server] [Proxy] Potential Slowloris DoS (Internal: Low) - Closed
Issue: The test infrastructure's HTTP server had been instantiated without setting ReadHeaderTimeout, ReadTimeout, WriteTimeout, IdleTimeout, or limiting header sizes, leaving it susceptible to Slowloris-style denial of service attacks.
Fix: We added default HTTP server timeouts. We recommend that admins use a load-balancer/reverse proxy in front of authentik in production, which would have different timeout settings.
I1: [Server] [RADIUS] RADIUS Message-Authenticator Validation
Issue: RADIUS Message-Authenticator validation logic appeared to be inverted, causing valid packets to be rejected and weakening the integrity check.
RADIUS Message-Authenticator validation is the process of verifying the integrity and authenticity of a RADIUS packet using the Message-Authenticator attribute.
Although the issue is currently theoretical, correctly authenticated RADIUS messages may be rejected, causing authentication failures and a potential denial-of-service.
Improvement: This was initially fixed but later reverted; we're testing our RADIUS implementation with different clients to resolve the underlying bug that required the fix to be reverted.
Conclusion
We encourage an open and ongoing communication with our users and community. For more information abut our security stance, read our Security Policy, Hardening authentik, and our other security-related documentation. If you have any questions or feedback you can reach us on GitHub, Discord, or via email. Please follow our security policy for reporting any security concerns or vulnerabilities.