GHSA-5GHQ-42RG-769X

Vulnerability from github – Published: 2026-04-06 17:53 – Updated: 2026-04-09 14:31
VLAI?
Summary
CI4MS: Company Information Public-Facing Page Full Platform Compromise & Full Account Takeover for All Roles & Privilege-Escalation via System Settings Company Information Stored DOM XSS
Details

Summary

Vulnerability: Stored DOM XSS in main landing page via System Settings – Company Information (Persistent Payload Injection)

  • Stored Cross-Site Scripting via Unsanitized Company Information Configuration Fields

Description

The application fails to properly sanitize user-controlled input within System Settings – Company Information. Several administrative configuration fields accept attacker-controlled input that is stored server-side and later rendered without proper output encoding.

Affected fields include, but are not limited to: 1. Company Name 2. Slogan 3. Company Phone 4. Company Mobile 5. Company Email 6. Google Maps iframe link 7. Company Logo and other media-related fields

These values are persisted in the database and rendered unsafely on public-facing pages only, such as the main landing page. There is no execution in the administrative dashboard—the vulnerability only impacts the public frontend.

Unlike the same-page stored DOM XSS vulnerability, this issue executes only on separate public-facing pages and not on the settings page itself.

Affected Functionality

  • System Settings – Company Information configuration
  • Public-facing page rendering (main landing page and other public pages)
  • Storage and retrieval of company information values

Attack Scenario

  • An attacker injects a malicious JavaScript payload into one or more Company Information fields.
  • The application stores these values without sanitization or encoding.
  • The payload is rendered only on public-facing pages, including the main landing page.
  • The payload executes automatically in the browser context of unauthenticated visitors and authenticated users who access the public site.

Impact

  • Persistent Stored XSS
  • Execution of arbitrary JavaScript in visitors’ browsers
  • Potential account takeover if cookies are not secured
  • Platform-wide public-facing compromise
  • Full compromise of any user interacting with the affected pages

Endpoints: - /backend/settings/ (Company Information injection only, not execution) - Main landing page - Other public-facing application pages

Steps To Reproduce (POC)

  1. Navigate to System Settings → Company Information
  2. Insert an XSS payload into any Company Information field such as: <img src=x onerror=alert(document.domain)>
  3. Save the settings
  4. Visit the public-facing main landing page or other public pages
  5. Observe the XSS payload executing automatically

Remediation

  • Never use .html() again or any innerHTML-style like JS in your PHP, or any other sink, even if user inputs that flow into them are not clear, they still represent real world danger as an attacker can make use of this to exploit the application via XSS. And do HTML Encoding as much as possible and always do Sanitization, theres no sanitization there unfortunately. Also apply CSP, HttpOnly, SameSite, and Secure upon all application, they reduce severity of XSS & escalated-CSRF via XSS and do great jobs
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.31.1.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "ci4-cms-erp/ci4ms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.31.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35035"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-06T17:53:02Z",
    "nvd_published_at": "2026-04-06T17:17:12Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n### **Vulnerability: Stored DOM XSS in main landing page via System Settings \u2013 Company Information (Persistent Payload Injection)**\n- Stored Cross-Site Scripting via Unsanitized Company Information Configuration Fields\n\n### Description\nThe application fails to properly sanitize user-controlled input within **System Settings \u2013 Company Information**. Several administrative configuration fields accept attacker-controlled input that is stored server-side and later rendered without proper output encoding.\n\nAffected fields include, but are not limited to:\n1. Company Name\n2. Slogan\n3. Company Phone\n4. Company Mobile\n5. Company Email\n6. Google Maps iframe link\n7. Company Logo and other media-related fields\n\nThese values are persisted in the database and rendered unsafely on **public-facing pages only**, such as the main landing page. **There is no execution in the administrative dashboard**\u2014the vulnerability only impacts the public frontend. \n\n**Unlike the same-page stored DOM XSS vulnerability, this issue executes only on separate public-facing pages and not on the settings page itself.**\n\n### Affected Functionality\n- System Settings \u2013 Company Information configuration\n- **Public-facing page rendering (main landing page and other public pages)**\n- Storage and retrieval of company information values\n\n### Attack Scenario\n- An attacker injects a malicious JavaScript payload into one or more Company Information fields.\n- The application stores these values without sanitization or encoding.\n- The payload is rendered only on **public-facing pages**, including the main landing page.\n- The payload executes automatically in the browser context of **unauthenticated visitors and authenticated users** who access the public site.\n\n### Impact\n- Persistent Stored XSS\n- Execution of arbitrary JavaScript in visitors\u2019 browsers\n- Potential account takeover if cookies are not secured\n- Platform-wide public-facing compromise\n- Full compromise of any user interacting with the affected pages\n\nEndpoints:\n- `/backend/settings/` (Company Information injection only, not execution)\n- Main landing page\n- Other public-facing application pages\n\n## Steps To Reproduce (POC)\n1. Navigate to System Settings \u2192 Company Information\n2. Insert an XSS payload into any Company Information field such as:\n`\u003cimg src=x onerror=alert(document.domain)\u003e`\n3. Save the settings\n4. Visit the **public-facing main landing page** or other public pages\n5. Observe the XSS payload executing automatically\n\n## Remediation\n- Never use .html() again or any innerHTML-style like JS in your PHP, or any other sink, even if user inputs that flow into them are not clear, they still represent real world danger as an attacker can make use of this to exploit the application via XSS. And do HTML Encoding as much as possible and always do Sanitization, theres no sanitization there unfortunately. Also apply CSP, HttpOnly, SameSite, and Secure upon all application, they reduce severity of XSS \u0026 escalated-CSRF via XSS and do great jobs",
  "id": "GHSA-5ghq-42rg-769x",
  "modified": "2026-04-09T14:31:58Z",
  "published": "2026-04-06T17:53:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/security/advisories/GHSA-5ghq-42rg-769x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35035"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ci4-cms-erp/ci4ms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/releases/tag/0.31.2.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CI4MS: Company Information Public-Facing Page Full Platform Compromise \u0026 Full Account Takeover for All Roles \u0026 Privilege-Escalation via System Settings Company Information Stored DOM XSS"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…