CVE-2026-39322
Received Received - Intake
Session Fixation in PolarLearn Auth Allows Unauthorized Access

Publication date: 2026-04-07

Last updated on: 2026-04-14

Assigner: GitHub, Inc.

Description
PolarLearn is a free and open-source learning program. In 0-PRERELEASE-15 and earlier, POST /api/v1/auth/sign-in creates a valid session for banned accounts before verifying the supplied password. That session is then accepted across authenticated /api routes, enabling account data access and authenticated actions as the banned user.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-07
Last Modified
2026-04-14
Generated
2026-05-07
AI Q&A
2026-04-08
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
polarlearn polarlearn *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-287 When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability allows attackers to bypass authentication controls for banned accounts, enabling unauthorized access to sensitive account data and the ability to perform authenticated actions as the victim user.

Such unauthorized access and actions can lead to violations of data protection and privacy regulations like GDPR and HIPAA, which require strict controls on access to personal and sensitive information.

Because the flaw results in high impact on confidentiality and integrity, it increases the risk of non-compliance with these standards, potentially leading to legal and regulatory consequences.


Can you explain this vulnerability to me?

CVE-2026-39322 is a critical authentication vulnerability in the PolarLearn software (versions up to v0-PRERELEASE-15). The issue occurs in the POST /api/v1/auth/sign-in endpoint, where the system creates a valid session for banned user accounts before verifying the supplied password.

Specifically, when a banned user attempts to sign in, the system loads the user record and computes a hash of the provided password but returns early if the user is banned. Instead of rejecting the login, it creates a session for the banned user without checking the password. This session is then accepted by all authenticated API routes.

As a result, an attacker who knows the email address of a banned user can log in as that user with any password, gaining unauthorized access to account data and the ability to perform authenticated actions as the banned user.


How can this vulnerability impact me? :

This vulnerability can have severe impacts including unauthorized access to sensitive account data and the ability to perform actions on behalf of banned users.

  • Attackers can log in as banned users without knowing their passwords.
  • Attackers can access sensitive information such as account settings and exported data.
  • Attackers can perform authenticated API actions, potentially altering data or performing other unauthorized operations.
  • The vulnerability requires no privileges and no user interaction, making it easier to exploit.

How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring attempts to authenticate banned user accounts via the POST /api/v1/auth/sign-in endpoint. Specifically, look for sessions being created for banned accounts without proper password verification.

You can detect suspicious activity by checking logs for sign-in attempts where banned users successfully create sessions. Network traffic analysis tools can be used to inspect POST requests to /api/v1/auth/sign-in and verify if sessions are being created for banned accounts.

Example commands to detect such activity might include:

  • Using grep to find sign-in attempts for banned users in server logs: grep 'POST /api/v1/auth/sign-in' /path/to/logfile | grep 'banned'
  • Using curl to test if a banned user can create a session without correct password: curl -X POST https://yourserver/api/v1/auth/sign-in -d '{"email":"[email protected]","password":"wrongpassword"}' -H 'Content-Type: application/json' -v
  • Using network monitoring tools (e.g., Wireshark or tcpdump) to capture and analyze POST requests to /api/v1/auth/sign-in for suspicious session creation.

What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include restricting access to the vulnerable endpoint and monitoring for suspicious activity involving banned accounts.

Since no patch is available, consider implementing temporary access controls such as:

  • Blocking or rate-limiting POST requests to /api/v1/auth/sign-in for banned user accounts.
  • Enforcing additional verification steps (e.g., CAPTCHA) if not already enabled.
  • Manually reviewing and disabling banned accounts or removing them from the system until a patch is released.

Additionally, monitor logs for unauthorized access attempts and consider alerting on suspicious session creations for banned users.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart