{"id":"CVE-2025-53942","aliases":["BIT-authentik-2025-53942","EUVD-2025-22471","GHSA-9g4j-v8w5-7x42","GO-2025-3822","SUSE-SU-2025:02912-1","openSUSE-SU-2025:15434-1"],"status":"published","title":"authentik has an insufficient check for account active status during OAuth/SAML authentication","description":"authentik is an open-source Identity Provider that emphasizes flexibility and versatility, with support for a wide set of protocols. In versions 2025.4.4 and earlier, as well as versions 2025.6.0-rc1 through 2025.6.3, deactivated users who registered through OAuth/SAML or linked their accounts to OAuth/SAML providers can still retain partial access to the system despite their accounts being deactivated. They end up in a half-authenticated state where they cannot access the API but crucially they can authorize applications if they know the URL of the application. To workaround this issue, developers can add an expression policy to the user login stage on the respective authentication flow with the expression of return request.context[\"pending_user\"].is_active. This modification ensures that the return statement only activates the user login stage when the user is active. This issue is fixed in versions authentik 2025.4.4 and 2025.6.4.","severity":{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00579,"percentile":0.48166,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-269"],"published":"2025-07-22T14:31:12Z","modified":"2026-10-28T02:30:33Z","fixes":[{"ecosystem":"Go","package":"goauthentik.io","fixed_in":["0.0.0-20250722122105-7a4c6b9b50f8"],"sources":["ghsa","osv"]},{"ecosystem":"Bitnami","package":"authentik","fixed_in":["2025.4.4","2025.6.4"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"goauthentik.io","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.0-20250722122105-7a4c6b9b50f8"}]}]},{"source":"osv","ecosystem":"Bitnami","package":"authentik","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"2025.4.4"},{"introduced":"2025.6.0"},{"fixed":"2025.6.4"}]}]},{"source":"osv","ecosystem":"Go","package":"goauthentik.io","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.0.0-20250722122105-7a4c6b9b50f8"}]}]},{"source":"osv","ecosystem":"Go","package":"goauthentik.io","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Package Hub 15 SP6","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20250814T182633-150000.1.98.1"}]}],"bundled":31},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20250814T182633-150000.1.98.1"}]}],"bundled":31},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20250811T192933-1.1"}]}],"bundled":29}],"products":[{"vendor":"goauthentik","product":"authentik"}],"references":[{"url":"https://github.com/goauthentik/authentik/security/advisories/GHSA-9g4j-v8w5-7x42","tags":["x_refsource_CONFIRM","Vendor Advisory","advisory","web"]},{"url":"https://github.com/goauthentik/authentik/commit/7a4c6b9b50f8b837133a7a1fd2cb9b7f18a145cd","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/goauthentik/authentik/commit/c3629d12bfe3d32d3dc8f85c0ee1f087a55dde8f","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/goauthentik/authentik/commit/ce3f9e3763c1778bf3a16b98c95d10f4091436ab","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-53942","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-9g4j-v8w5-7x42"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/53xxx/CVE-2025-53942.json","tags":["advisory"]},{"url":"https://github.com/goauthentik/authentik","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202502912-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2021-21411","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-44906","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-44779","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-47907","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-50738","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-53534","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-53942","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54386","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54388","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54410","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54424","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54576","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54799","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54801","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54996","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54997","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54998","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54999","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-55000","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-55001","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-55003","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-5999","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6000","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6004","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6011","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6013","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6014","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6015","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6037","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-7195","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-8341","tags":["web"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2025-53942","title":"authentik has an insufficient check for account active status during OAuth/SAML authentication","description":"authentik is an open-source Identity Provider that emphasizes flexibility and versatility, with support for a wide set of protocols. In versions 2025.4.4 and earlier, as well as versions 2025.6.0-rc1 through 2025.6.3, deactivated users who registered through OAuth/SAML or linked their accounts to OAuth/SAML providers can still retain partial access to the system despite their accounts being deactivated. They end up in a half-authenticated state where they cannot access the API but crucially they can authorize applications if they know the URL of the application. To workaround this issue, developers can add an expression policy to the user login stage on the respective authentication flow with the expression of return request.context[\"pending_user\"].is_active. This modification ensures that the return statement only activates the user login stage when the user is active. This issue is fixed in versions authentik 2025.4.4 and 2025.6.4.","status":"published","published":"2025-07-23T20:35:07.243Z","modified":"2025-07-23T20:49:29.415Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H","level":"high","assessor":"cna"}],"cwes":["CWE-269"],"updated_at":"2026-11-02T14:32:49.503917Z"}],"euvd":[{"id":"EUVD-2025-22471","description":"authentik is an open-source Identity Provider that emphasizes flexibility and versatility, with support for a wide set of protocols. In versions 2025.4.4 and earlier, as well as versions 2025.6.0-rc1 through 2025.6.3, deactivated users who registered through OAuth/SAML or linked their accounts to OAuth/SAML providers can still retain partial access to the system despite their accounts being deactivated. They end up in a half-authenticated state where they cannot access the API but crucially they can authorize applications if they know the URL of the application. To workaround this issue, developers can add an expression policy to the user login stage on the respective authentication flow with the expression of return request.context[\"pending_user\"].is_active. This modification ensures that the return statement only activates the user login stage when the user is active. This issue is fixed in versions authentik 2025.4.4 and 2025.6.4.","status":"published","published":"2025-07-23T20:35:07Z","modified":"2025-07-23T20:49:29Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H","level":"high"}],"updated_at":"2026-11-02T20:32:04.806066Z"}],"ghsa":[{"id":"GHSA-9g4j-v8w5-7x42","title":"Authentik has insufficient check for account active status when authenticating with OAuth/SAML Sources","description":"### Summary\n\nDeactivated users that had either enrolled via OAuth/SAML or had their account connected to an OAuth/SAML account can still partially access authentik even if their account is deactivated. They end up in a half-authenticated state where they cannot access the API but crucially they can authorize applications if they know the URL of the application.\n\n### Patches\n\nauthentik 2025.4.4 and 2025.6.4 fix this issue.\n\n### Workarounds\n\nAdding an expression policy to the user login stage on the respective authentication flow with the expression of\n\n```py\nreturn request.context[\"pending_user\"].is_active\n```\n\nThis expression will only activate the user login stage when the user is active.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n- Email us at [security@goauthentik.io](mailto:security@goauthentik.io).","status":"published","published":"2025-07-22T14:31:12Z","modified":"2025-07-23T22:15:11Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H","level":"high"}],"cwes":["CWE-269"],"updated_at":"2026-11-02T14:38:51.864708Z"}],"nvd":[{"id":"CVE-2025-53942","description":"authentik is an open-source Identity Provider that emphasizes flexibility and versatility, with support for a wide set of protocols. In versions 2025.4.4 and earlier, as well as versions 2025.6.0-rc1 through 2025.6.3, deactivated users who registered through OAuth/SAML or linked their accounts to OAuth/SAML providers can still retain partial access to the system despite their accounts being deactivated. They end up in a half-authenticated state where they cannot access the API but crucially they can authorize applications if they know the URL of the application. To workaround this issue, developers can add an expression policy to the user login stage on the respective authentication flow with the expression of return request.context[\"pending_user\"].is_active. This modification ensures that the return statement only activates the user login stage when the user is active. This issue is fixed in versions authentik 2025.4.4 and 2025.6.4.","status":"published","published":"2025-07-23T21:15:26.777Z","modified":"2026-06-17T09:39:10.103Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H/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","level":"high","assessor":"secondary"},{"version":"3.1","score":7.4,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"high","assessor":"primary"}],"cwes":["CWE-269"],"updated_at":"2026-11-02T14:11:19.382856Z"}],"osv":[{"id":"CVE-2025-53942","title":"authentik has an insufficient check for account active status during OAuth/SAML authentication","description":"authentik is an open-source Identity Provider that emphasizes flexibility and versatility, with support for a wide set of protocols. In versions 2025.4.4 and earlier, as well as versions 2025.6.0-rc1 through 2025.6.3, deactivated users who registered through OAuth/SAML or linked their accounts to OAuth/SAML providers can still retain partial access to the system despite their accounts being deactivated. They end up in a half-authenticated state where they cannot access the API but crucially they can authorize applications if they know the URL of the application. To workaround this issue, developers can add an expression policy to the user login stage on the respective authentication flow with the expression of return request.context[\"pending_user\"].is_active. This modification ensures that the return statement only activates the user login stage when the user is active. This issue is fixed in versions authentik 2025.4.4 and 2025.6.4.","status":"published","published":"2025-07-23T20:35:07.243Z","modified":"2026-10-28T02:30:33.150955381Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H","level":"high"}],"cwes":["CWE-269"],"updated_at":"2026-11-02T15:44:50.45326Z"},{"id":"GHSA-9g4j-v8w5-7x42","title":"Authentik has insufficient check for account active status when authenticating with OAuth/SAML Sources","description":"### Summary\n\nDeactivated users that had either enrolled via OAuth/SAML or had their account connected to an OAuth/SAML account can still partially access authentik even if their account is deactivated. They end up in a half-authenticated state where they cannot access the API but crucially they can authorize applications if they know the URL of the application.\n\n### Patches\n\nauthentik 2025.4.4 and 2025.6.4 fix this issue.\n\n### Workarounds\n\nAdding an expression policy to the user login stage on the respective authentication flow with the expression of\n\n```py\nreturn request.context[\"pending_user\"].is_active\n```\n\nThis expression will only activate the user login stage when the user is active.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n- Email us at [security@goauthentik.io](mailto:security@goauthentik.io).","status":"published","published":"2025-07-22T14:31:12Z","modified":"2026-04-17T04:57:03.99207363Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H","level":"high"}],"cwes":["CWE-269"],"updated_at":"2026-11-02T15:46:43.875515Z"},{"id":"BIT-authentik-2025-53942","title":"authentik has an insufficient check for account active status during OAuth/SAML authentication","description":"authentik is an open-source Identity Provider that emphasizes flexibility and versatility, with support for a wide set of protocols. In versions 2025.4.4 and earlier, as well as versions 2025.6.0 through 2025.6.3, deactivated users who registered through OAuth/SAML or linked their accounts to OAuth/SAML providers can still retain partial access to the system despite their accounts being deactivated. They end up in a half-authenticated state where they cannot access the API but crucially they can authorize applications if they know the URL of the application. To workaround this issue, developers can add an expression policy to the user login stage on the respective authentication flow with the expression of return request.context[\"pending_user\"].is_active. This modification ensures that the return statement only activates the user login stage when the user is active. This issue is fixed in versions authentik 2025.4.4 and 2025.6.4.","status":"published","published":"2026-04-16T23:36:28.2Z","modified":"2026-09-08T08:45:50.92515966Z","updated_at":"2026-11-02T15:28:28.70813Z"},{"id":"GO-2025-3822","title":"Authentik has insufficient check for account active status when authenticating with OAuth/SAML Sources in goauthentik.io","description":"Authentik has insufficient check for account active status when authenticating with OAuth/SAML Sources in goauthentik.io.\n\nNOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.\n\n(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)\n\nThe additional affected modules and versions are: goauthentik.io before v0.0.0-20250722122105-7a4c6b9b50f8.","status":"published","published":"2025-08-11T17:24:51Z","modified":"2026-04-17T04:57:03.99207363Z","updated_at":"2026-11-02T15:47:01.728182Z"},{"id":"openSUSE-SU-2025:15434-1","title":"govulncheck-vulndb-0.0.20250811T192933-1.1 on GA media","description":"These are all security issues fixed in the govulncheck-vulndb-0.0.20250811T192933-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2025-08-12T00:00:00Z","modified":"2026-03-23T04:53:46.634804Z","updated_at":"2026-11-02T16:58:37.810934Z"},{"id":"SUSE-SU-2025:02912-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20250814T182633 2025-08-14T18:26:33Z (jsc#PED-11136)\n\n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2025-3765 CVE-2024-44906 GHSA-h4h6-vccr-44h2\n  * GO-2025-3829 CVE-2025-54410 GHSA-4vq8-7jfc-9cvp\n\n- Update to version 0.0.20250811T192933 2025-08-11T19:29:33Z (jsc#PED-11136)\n  \n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2025-3822 CVE-2025-53942 GHSA-9g4j-v8w5-7x42\n  * GO-2025-3829 CVE-2025-54410 GHSA-4vq8-7jfc-9cvp\n  * GO-2025-3830 CVE-2025-54388 GHSA-x4rx-4gw3-53p4\n  * GO-2025-3831 CVE-2025-50738 GHSA-hfcf-79gh-f3jc\n  * GO-2025-3832 CVE-2021-21411 GHSA-652x-m2gr-hppm\n  * GO-2025-3833 CVE-2025-54576 GHSA-7rh7-c77v-6434\n  * GO-2025-3834 CVE-2025-54424 GHSA-8j63-96wh-wh3j\n  * GO-2025-3835 CVE-2025-54386 GHSA-q6gg-9f92-r9wg\n  * GO-2025-3836 CVE-2025-6037 GHSA-6c5r-4wfc-3mcx\n  * GO-2025-3837 CVE-2025-5999 GHSA-6h4p-m86h-hhgh\n  * GO-2025-3838 CVE-2025-6000 GHSA-mr4h-qf9j-f665\n  * GO-2025-3839 CVE-2025-6011 GHSA-mwgr-84fv-3jh9\n  * GO-2025-3840 CVE-2025-6004 GHSA-qgj7-fmq2-6cc4\n  * GO-2025-3841 CVE-2025-6014 GHSA-qv3p-fmv3-9hww\n  * GO-2025-3842 CVE-2025-6015 GHSA-v6r4-35f9-9rpw\n  * GO-2025-3843 CVE-2025-8341 GHSA-3c93-92r7-j934\n  * GO-2025-3844 CVE-2025-53534 GHSA-fm3m-jrgm-5ppg\n  * GO-2025-3845 CVE-2025-54801 GHSA-qx2q-88mx-vhg7\n  * GO-2025-3847 CVE-2025-54799 GHSA-q82r-2j7m-9rv4\n  * GO-2025-3848 CVE-2025-6013 GHSA-7rx2-769v-hrwf\n  * GO-2025-3851 CVE-2025-44779 GHSA-93jv-pvg8-hf3v\n  * GO-2025-3852 CVE-2025-7195 GHSA-856v-8qm2-9wjv\n  * GO-2025-3853 CVE-2025-55000 GHSA-f7c3-mhj2-9pvg\n  * GO-2025-3854 CVE-2025-54999 GHSA-hh28-h22f-8357\n  * GO-2025-3855 CVE-2025-54998 GHSA-j3xv-7fxp-gfhx\n  * GO-2025-3856 CVE-2025-55003 GHSA-rxp7-9q75-vj3p\n  * GO-2025-3857 CVE-2025-54996 GHSA-vf84-mxrq-crqc\n  * GO-2025-3858 CVE-2025-54997 GHSA-xp75-r577-cvhp\n  * GO-2025-3859 CVE-2025-55001 GHSA-2q8q-8fgw-9p6p\n\n- Update to version 0.0.20250807T150727 2025-08-07T15:07:27Z (jsc#PED-11136)\n\n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2025-3849 CVE-2025-47907\n","status":"published","published":"2025-08-19T12:52:27Z","modified":"2026-03-23T04:49:48.54789Z","updated_at":"2026-11-02T15:53:57.111474Z"}]}}