Release: Merge release into master from: release/2.52.3

[github-actions]

Release triggered by rossops

[dryrunsecurity]

This pull request fixes a stale thread-local cache for System_Settings, changes Trivy severity selection to prefer the top-level Severity field over CVSS-derived severities, and adds external third-party scripts from static.reo.dev and assets.apollo.io in the docs; together these changes introduce risks that configuration changes may not take effect until cache invalidation is addressed, may understate vulnerability risk by preferring possibly lower top-level severities over CVSS, and expose the docs to supply-chain/client-side script risks due to unpinned third‑party scripts.

Stale Cache / Configuration Bypass in dojo/middleware.py

Vulnerability

Stale Cache / Configuration Bypass

Description

Before this patch, System_Settings were cached in a thread-local variable without a mechanism to invalidate the cache upon database updates. This meant that if security-critical settings within System_Settings were changed (e.g., JIRA webhook secrets, password policies, API error exposure), the application could continue to operate with the old, stale settings until the application was restarted or the thread-local cache was manually cleared. This could lead to security vulnerabilities such as authentication bypasses for JIRA webhooks or weaker password policy enforcement.

django-DefectDojo/dojo/middleware.py

Lines 115 to 118 in f1e363f

	models.signals.post_save.connect(DojoSytemSettingsMiddleware.cleanup, sender=System_Settings)
	def __call__(self, request):
	self.load()

Incorrect Severity Assignment in dojo/tools/trivy/parser.py

Vulnerability

Incorrect Severity Assignment

Description

The updated logic in dojo/tools/trivy/parser.py prioritizes the top-level Severity field from Trivy scan results over severities derived from CVSS scores. While the intent might be to use a readily available severity, this can lead to a downgrade of the actual risk. For instance, a vulnerability might have a top-level Severity of 'LOW' but a CVSSv3 score that translates to 'CRITICAL'. By taking the 'LOW' severity first, the system would misrepresent the true risk, potentially causing high-risk vulnerabilities to be overlooked or deprioritized in DefectDojo.

django-DefectDojo/dojo/tools/trivy/parser.py

Lines 266 to 282 in f1e363f

	if cvss_data := parse_cvss_data(cvssclass.get("V3Vector", "")):
	cvssv3 = cvss_data.get("cvssv3")
	cvssv3_score = cvss_data.get("cvssv3_score")
	if severity is None:
	severity = cvss_data.get("severity")
	elif (cvss_v3_score := cvssclass.get("V3Score")) is not None:
	cvssv3_score = cvss_v3_score
	if severity is None:
	severity = self.convert_cvss_score(cvss_v3_score)
	elif (cvss_v2_score := cvssclass.get("V2Score")) is not None:
	if severity is None:
	severity = self.convert_cvss_score(cvss_v2_score)
	if severity is None:
	severity = self.convert_cvss_score(None)
	if target_class in {"os-pkgs", "lang-pkgs"}:
	file_path = vuln.get("PkgPath")
	if file_path is None:

Third-Party Script Inclusion in docs/layouts/_partials/head/script-header.html

Vulnerability

Third-Party Script Inclusion

Description

The documentation site includes two external JavaScript files from static.reo.dev and assets.apollo.io. These scripts are likely used for marketing, analytics, or customer engagement. The dynamic nature of their URLs prevents the effective use of Subresource Integrity (SRI). If these third-party domains are compromised, an attacker could inject malicious JavaScript into the documentation site, leading to defacement, phishing, or other client-side attacks.

django-DefectDojo/docs/layouts/_partials/head/script-header.html

Lines 1 to 12 in f1e363f

	<!-- Insert scripts NOT needed by stylesheets here -->
	<!-- Start of Reo Javascript -->
	<script type="text/javascript">
	!function () { var e, t, n; e = "a92cfcfa51eca96", t = function () { Reo.init({ clientID: "a92cfcfa51eca96" }) }, (n = document.createElement("script")).src = "https://static.reo.dev/" + e + "/reo.js", n.async = !0, n.onload = t, document.head.appendChild(n) }();
	</script>
	<!-- End of Reo Javascript -->
	<script>function initApollo() {
	var n = Math.random().toString(36).substring(7), o = document.createElement("script");
	o.src = "https://assets.apollo.io/micro/website-tracker/tracker.iife.js?nocache=" + n, o.async = !0, o.defer = !0,
	o.onload = function () { window.trackingFunctions.onLoad({ appId: "68ffca00b8c4dc001de5fec3" }) },
	document.head.appendChild(o)
	} initApollo();</script>

---

All finding details can be found in the DryRun Security Dashboard.