Authentication bypass in ThimPress LearnPress, Sepay Payment plugin

Authentication Bypass Using an Alternate Path or Channel vulnerability in ThimPress LearnPress – Sepay Payment learnpress-sepay-payment allows Authentication Abuse.This issue affects LearnPress – Sepay Payment: from n/a through <= 4.0.0.

• The learnpress-sepay-payment package in ThimPress LearnPress, Sepay Payment is affected from n/a through and including <= 4.0.0 under the record's custom version scheme.
• The record sets default_status to unaffected outside the stated affected range.
• The recorded status change marks 4.0.1 as unaffected; this is the confirmed change point and should not be treated as proof that every other release branch has been independently verified.

ThimPress LearnPress, Sepay Payment is affected by CWE-288, where authentication can be bypassed through an alternate path or channel. An unauthenticated remote attacker may be able to use this path to reach or perform actions that should require authentication and authorization. The record identifies network reachability, no initial privileges, and no user interaction, but the supplied assessments differ on attack complexity. No endpoint, parameter, handler, request sequence, or specific action is disclosed. The implementation detail of the bypass and the practical action scope therefore remain unknown.

The flaw is remotely reachable, and Patchstack describes exploitation as requiring no initial authentication, low complexity, and no user interaction. The supplied record marks public_exploit as false, while real-world exploited status is not established in the provided data. The CISA ADP enrichment records exploitation as none and automatable as no; another assessment in the same record describes higher attack complexity. Because no endpoint, request sequence, or public exploit is disclosed, practical exploitability cannot be assessed in more detail from the available evidence.

The confirmed technical outcome is authentication abuse and possible unauthorized actions with the primary stated effect on integrity. The specific action, achieved privilege, and whether administrative control can be obtained are not established by the advisory. Patchstack's assessment describes unchanged scope and no confidentiality or availability impact, while the alternate CISA ADP assessment allocates impact differently across scope, confidentiality, and integrity. This disagreement limits confident conclusions about the exact consequences from the available record.

The flaw can break the website's authentication boundary and permit unauthorized changes to state managed by WordPress or the plugin. This could lead to unauthorized changes to protected configuration, content, or business workflows, but the available evidence does not identify specific records, accounts, transactions, or data that can be affected. The presence of the vulnerability alone does not establish that compromise or data loss occurred. Inventory and update activity are the most important confirmed risk-reduction actions.

1. Update learnpress-sepay-payment to 4.0.1, the release recorded as patched.
2. After updating, verify the deployed version on every site and ensure that the vulnerable copy is no longer loaded or active.
3. If the update cannot be deployed, the reviewed record and advisory provide no separately confirmed mitigation. Consider temporary removal of the plugin from higher-risk sites, but do not represent that as a vendor-confirmed fix.
4. Review the exposure period for unauthorized changes and investigate any suspicious activity.
5. Do not assume that every release after the recorded patched release has been verified unless current plugin metadata or an authoritative advisory confirms it.

1. Inventory WordPress sites with the plugin package slug learnpress-sepay-payment active.
2. Record the deployed version and compare it with the confirmed unaffected release identified in remediation.
3. Review audit logs, administrative logs, and application change records for unauthorized state changes or account activity during the exposure period.
4. Prioritize review of unauthenticated network requests followed by data or privilege changes, but treat this as precautionary monitoring because the advisory provides no endpoint, IOC, or specific log signature.
5. Do not treat the absence of suspicious log entries as proof that a system is safe.