Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go

GHSA-2j42-h78h-q4fg

CRITICAL

Beego allows Reflected/Stored XSS in Beego's RenderForm() Function Due to Unescaped User Input

Also known asCVE-2025-30223GO-2025-3585
Published
Mar 31, 2025
Updated
Feb 4, 2026
Affected
2 pkgs
Patched
1 / 2
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
0.6%probability of exploitation in next 30 days
Lower Risk43th percentile+0.12%
0.00%0.36%0.71%1.07%0.1%0.6%Dec 25Apr 26Jun 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

2 pkgs affected
🐹github.com/beego/beego/v2🐹github.com/beego/beego

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

A Cross-Site Scripting (XSS) vulnerability exists in Beego's RenderForm() function due to improper HTML escaping of user-controlled data. This vulnerability allows attackers to inject malicious JavaScript code that executes in victims' browsers, potentially leading to session hijacking, credential theft, or account takeover. The vulnerability affects any application using Beego's RenderForm() function with user-provided data. Since it is a high-level function generating an entire form markup, many developers would assume it automatically escapes attributes (the way most frameworks do).

Details

The vulnerability is located in the renderFormField() function in Beego's templatefunc.go file (around lines 316-356). This function directly injects user-provided values into HTML without proper escaping:

return fmt.Sprintf(`%v<input%v%v name="%v" type="%v" value="%v"%v>`, 
    label, id, class, name, fType, value, requiredString)

None of the values (label, id, class, name, value) are properly HTML-escaped before being inserted into the HTML template. This allows attackers to break out of the attribute context or inject HTML tags directly. The vulnerability can be exploited in two main ways:

  • Attribute Injection: By injecting code into fields like DisplayName, an attacker can break out of the attribute context and execute JavaScript.
  • Content Injection: By injecting HTML tags into textarea content, an attacker can execute JavaScript.

The RenderForm() function returns template.HTML, which bypasses Go's automatic HTML escaping, making this vulnerability particularly dangerous.

PoC

Retrieve the following (secret) gist: https://gist.github.com/thevilledev/8fd0cab3f098320aa9daab04be59fd2b

To run it:

go mod init beego-xss-poc
go mod tidy
go run poc.go

Open your browser and navigate to http://localhost:8080/

The application demonstrates the vulnerability through several examples:

  • /profile - Shows a profile with malicious data in the Display Name and Bio fields
  • /admin - Shows multiple user profiles, including one with malicious data
  • /submit - Allows you to create your own profile with malicious data

In addition, you may use this Go test in templatefunc_test.go. The test passes, validating the vulnerability.

func TestRenderFormXSSVulnerability(t *testing.T) {
	type UserProfile struct {
		DisplayName string `form:"displayName,text,Name:"`
		Bio         string `form:",textarea"`
	}

	// Test case 1: Attribute injection in input field
	maliciousUser := UserProfile{
		DisplayName: `" onmouseover="alert('XSS')" data-malicious="`,
		Bio:         "Normal bio text",
	}

	output := RenderForm(&maliciousUser)

	// The vulnerable output would contain the unescaped JavaScript
	if !strings.Contains(string(output), `onmouseover="alert('XSS')"`) {
		t.Errorf("Expected XSS vulnerability in attribute, but got safe output: %v", output)
	}

	// Test case 2: Script injection in textarea
	maliciousUser2 := UserProfile{
		DisplayName: "Normal Name",
		Bio:         `</textarea><script>alert('XSS')</script><textarea>`,
	}

	output = RenderForm(&maliciousUser2)

	// The vulnerable output would contain the unescaped script tag
	if !strings.Contains(string(output), `</textarea><script>alert('XSS')`) {
		t.Errorf("Expected XSS vulnerability in textarea content, but got safe output: %v", output)
	}
}

Impact

This is a high-severity vulnerability with the following impacts:

  • Cross-Site Scripting (XSS): Allows execution of arbitrary JavaScript in the context of the victim's browser.
  • Session Hijacking: Attackers can steal session cookies and impersonate victims.
  • Credential Theft: Attackers can create fake login forms to steal credentials.
  • Account Takeover: Attackers can perform actions on behalf of the victim.
  • Data Exfiltration: Sensitive data visible in the browser can be stolen.

This is particularly concerning in admin panels or user management interfaces where one user's data is displayed to another user (typically an administrator).

Mitigation

The vulnerability can be fixed by properly escaping all user-provided values before inserting them into HTML, for example:

// Convert value to string and escape it
valueStr := ""
if value != nil {
    valueStr = template.HTMLEscapeString(fmt.Sprintf("%v", value))
}

// Escape the name and label
escapedName := template.HTMLEscapeString(name)
escapedLabel := template.HTMLEscapeString(label)
escapedType := template.HTMLEscapeString(fType)

return fmt.Sprintf(`%v<input%v%v name="%v" type="%v" value="%v"%v>`, 
    escapedLabel, id, class, escapedName, escapedType, valueStr, requiredString)

Affected Packages

2 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/beego/beego/v2all versions2.3.6
🐹Gogithub.com/beego/beegoall versionsNo fix

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/beego/beego/v2. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/beego/beego/v2 to 2.3.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2j42-h78h-q4fg is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-2j42-h78h-q4fg is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-2j42-h78h-q4fg. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary A Cross-Site Scripting (XSS) vulnerability exists in Beego's `RenderForm()` function due to improper HTML escaping of user-controlled data. This vulnerability allows attackers to inject malicious JavaScript code that executes in victims' browsers, potentially leading to session hijacking, credential theft, or account takeover. The vulnerability affects any application using Beego's `RenderForm()` function with user-provided data. Since it is a high-level function generating an entire form markup, many developers would assume it automatically escapes attributes (the way most framew
O3 Security · Impact-Aware SCA

Is GHSA-2j42-h78h-q4fg in your dependencies?

O3 detects GHSA-2j42-h78h-q4fg across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.