Just like the WordPress vulnerability we recently discovered and reported, the Alert Logic cybersecurity researchers recently discovered and reported another flaw in the WordPress WP Live Chat plugin. As part of our continued work on coverage for a cluster of vulnerabilities in the WP Live Chat plugin for WordPress, we uncovered a critical authentication bypass (CWE-287 / OWASP Top 10: A2: 2017-Broken Authentication) in version 8.0.32 and earlier. This bypass allows an attacker to gain access to the REST API functionality without valid credentials—enabling exfiltration of chat logs and the ability to manipulate chat sessions.

Following our responsible disclosure policy, we reported the issue to the vendor and Mitre (CVE-2019-12498) and have worked with them to release a patch and raise the bar for security for all users of the software. The vendor in question is commended for being responsive and open to resolving the bug quickly.

Note that we had not seen attackers attempt this specific bypass in our customer data, and do not believe that it was being actively exploited.

Technical Analysis

The restricted REST API endpoints of the affected versions of WP Live Chat are vulnerable to abuse by unauthenticated remote attackers due to a flaw in the ‘wplc_api_permission_check()’ function.


Source: /wp-live-chat-support/modules/api/wplc-api-routes.php [Lines: 11-63, v8.0.32]

The above series of ‘register_rest_route()’ calls define those REST API endpoints which should have access restrictions due to the nature of the functionality they expose. Each restricted endpoint shares the same ‘permission_callback’ function, namely the ‘wplc_api_permission_check()’ function which will be explored shortly.

A potential attacker could make use of all these endpoints for malicious purposes including:

  • Extracting the entire chat history for all chat sessions
  • Injecting arbitrary messages into active chat sessions and posing as an agent
  • Editing injected messages to retroactively conceal what any injected messages contained
  • Arbitrarily ending active chat sessions as part of a denial of service (DoS) attack


The above ternary statement is the key permission checking logic and leverages two core WordPress functions. The function ‘is_user_logged_in()’ is a Boolean which retrieves the current WP_User instance and calls the ‘exists()’ method. The method will return true if the user id exists in the database and by extension confirms the user is logged in and has a valid WP_User instance.

If the ‘is_user_logged_in()’ call returns true, the first statement is used to continue validating the request via the ‘check_ajax_referer()’ function. The additional validation checks will compare the submitted nonce value to confirm that the request is valid.

Should the ‘is_user_logged_in()’ call return false, the ternary will return the second statement – the Boolean value true. It is at this point that the authentication bypass exists, as the result of a successful ‘check_ajax_referer()’ call will also return true and thus permit access to the endpoint in question.

To summarize, the above ternary statement has the following possible outcomes:

  1. The request originated from a user who is logged in and submitted all the correct nonce values. The return value will be ‘true’ as provided by the ‘check_ajax_referer()’ call – access to the REST endpoint is permitted.
  2. The request originated from a user who is logged in and submitted invalid nonce values. The return value will be ‘false’ as returned by the ‘check_ajax_referer()’ call – access to the REST endpoint is denied.
  3. The request originated from a user who is not logged in and may or may not have submitted the correct nonce values. The return value will be ‘true’ as provided by the second statement of the ternary – access to the REST endpoint is permitted.

This effectively allows any unauthenticated user to access the restricted REST API endpoints and only enforces additional authorization checks for users who are authenticated. Unauthenticated users are granted immediate access without any further checks.

Remediation and Mitigation

The primary resolution of this vulnerability is to update the plugin to the latest version. If this cannot be achieved, then mitigation options may include:

  • Virtual patching using a WAF to filter traffic destined for the WP Live Chat Support REST endpoint

Alert Logic can detect this issue via Authentication Scanning, Exposure ID : 131393 Name ‘CVE-2019-12498 – WP Live Chat Support – Authentication Bypass Issue’.

Responsible Disclosure

What When
Initial contact with vendor 28 May 2019
Vulnerability disclosed to vendor 29 May 2019
Vendor accepts vulnerability. Begins working on patch 30 May 2019
Submit to NVD. CVE assigned 31 May 2019
New version released. Confirmed no longer vulnerable 31 May 2019
Responsible Disclosure embargo lifted 10 June 2019

About Alert Logic Threat Research

Alert Logic routinely track the emergence and use of new exploits and vulnerabilities in the wild. This allows us to keep up with the latest exploit of choice of attackers and provide protection for our customers for their most critical threats.

Fortra's Alert Logic
About the Author
Fortra's Alert Logic

Related Post

Ready to protect your company with Alert Logic MDR?