Concrete CMS is a popular open-source content management system powering many government and enterprise websites. In late 2022, a worrying vulnerability — now tracked as CVE-2022-43693 — was revealed. This vulnerability allows attackers to perform Cross-Site Request Forgery (CSRF) attacks through the "out-of-the-box" core OAuth authentication service, letting them hijack accounts or perform actions as unsuspecting users.

This post breaks down CVE-2022-43693 in plain language, with code, demo scenarios, links to references, and practical advice.

What is CVE-2022-43693?

The bug is a missing "state" parameter in the OAuth implementation that ships by default with Concrete CMS. OAuth is often used to let users "log in with Google" or similar services. The "state" parameter is a core part of the OAuth spec, helping to protect against CSRF. Without it, attackers can trick users into authorizing unwanted requests.

How Does the Attack Work?

A CSRF attack abuses the trust a site has in a user's browser. Here’s how an attacker could abuse the Concrete CMS flaw:

Authorization Without State

- Since there is no unique state parameter, Concrete cannot tell if the OAuth response is meant for the current user session.
   - The victim unknowingly associates their session with the attacker’s account — or performs actions on behalf of the attacker.

Code Example: Exploiting the OAuth Flow

Here’s a simplified example using curl to show the missing 'state' parameter in action.

https://example.com/index.php/login/oauth2/authorize?client_id=attacker_client_id
&redirect_uri=https://attacker.com/receive
&response_type=code

Notice: No state parameter.
In the fixed version, state=XYZ would be present and checked.

The application doesn’t require or validate a state parameter, so it proceeds. The victim is logged in or performs actions as the attacker within Concrete CMS.

Demonstration (Python snippet)

While a full browser/cookies context is needed for a real attack, this code snippet shows the form of the vulnerable request:

import requests

# Attacker prepares this URL, no "state" included
vuln_oauth_url = (
    "https://targetsite.com/index.php/login/oauth2/authorize";
    "?client_id=attacker_client_id"
    "&redirect_uri=https://evil.com/";
    "&response_type=code"
)

# Victim's browser is tricked into visiting this link
print(f"Send this to victim: {vuln_oauth_url}")

The OAuth2 specification says the state parameter is REQUIRED to prevent CSRF

> "If the state parameter is present in the client authorization request, the authorization server MUST include the exact value received in the authorization response."
> — OAuth 2. Spec, RFC 6749 Section 10.12

It’s like a random, single-use "password" for each login attempt, tying browser sessions to OAuth requests.

In Concrete CMS’s vulnerable flow, this was missing, so nothing ties requests/responses to the originating session.

Let’s say you’re an admin for a Concrete CMS site. An attacker wants to steal your login. They

* Register their own account via OAuth, get their “code.”
* Craft a malicious link or embed it in a phishing email.
* You, the site admin, click the URL. Because there's no verification with state, the CMS just logs you in as the attacker, or forges settings changes, etc.

Fix Status

* Patched in Concrete CMS v9.1.2 and later.
* See official fix:  
 https://github.com/concretecms/concretecms/pull/10845
* CVE database reference:  
 NIST NVD: CVE-2022-43693
* Upstream issue:  
 HackerOne report 1660214

Educate Users:

Warn admins to never click odd-looking “login” or "authorize" links, especially those sent via email or chat.

Conclusion

_CVE-2022-43693_ shows how missing one parameter in an authentication protocol can jeopardize an entire platform. If you run Concrete CMS, update ASAP and never trust OAuth integrations that lack full CSRF protections. The state parameter may seem like a tiny thing, but it’s your shield against attacks like this.

Original References

- Concrete CMS Security Fix PR
- NVD CVE-2022-43693 Details
- RFC 6749 - OAuth 2. Spec, Section 10.12
- HackerOne Report 1660214


Stay updated, stay safe, and always double-check your OAuth! 👀

Timeline

Published on: 11/14/2022 17:15:00 UTC
Last modified on: 11/17/2022 21:55:00 UTC