Stored cross-site scripting in the OPNsense Core NTP GPS page

OPNsense is a FreeBSD based firewall and routing platform. Prior to version 26.1.11, the NTP GPS page stores the operator-supplied initcmd value in base64 form, applies legacy_html_escape_form_data() to the encoded string, and then uses base64_decode() to decode the value directly into the GPS initialization-command textarea in src/www/services_ntpd_gps.php. Because decoding occurs after escaping, stored HTML remains unescaped at the output sink. A user with page-services-ntp-gps privilege can store a value that closes the textarea, and script executes in the session of any user who later opens the GPS page. The script can read CSRF material and perform authenticated actions, including actions available to an administrator. This issue is fixed in version 26.1.11.

• 26.1 branch: Versions before 26.1.11 are affected; 26.1.11 is the confirmed patched release.
• 26.4 branch: Versions through 26.4.1 are affected; 26.4.1p1 is the confirmed patched release.
• The confirmed affected scope is OPNsense Core, specifically the NTP GPS configuration page and its GPS initialization-command field. Do not infer the status of other branches without checking the corresponding vendor advisory or release information.

The OPNsense NTP GPS page accepts an operator-supplied initcmd value and stores it in base64 form. The application applies legacy_html_escape_form_data() to the encoded string, then calls base64_decode() while writing the decoded content directly into the GPS initialization-command textarea in src/www/services_ntpd_gps.php. Because decoding occurs after escaping, stored HTML reaches the output sink without effective escaping. An authenticated user with the page-services-ntp-gps privilege can save content that closes the textarea, after which script executes in the session of any user who opens the GPS page. The available evidence does not show an additional validation layer that would prevent this condition.

The issue is reachable through the network-accessible administrative web interface. An attacker needs an authenticated account with the page-services-ntp-gps privilege to store the malicious content, and another user must open the GPS page for the script to execute in that user's session. The documented attack complexity is low, while user interaction is required. Public proof-of-concept material has been published. The available record does not establish whether the vulnerability has been exploited in the wild.

The vulnerability turns data stored by a low-privileged user into script running in another user's security context. The script can read CSRF material and send authenticated requests with the victim's authority, so an administrator opening the page could cause unintended administrative actions. This cross-session impact can affect the confidentiality and integrity of data or configuration accessible to the victim. The specific ability to access, modify, or create resources depends on the victim's privileges; no evidence establishes direct service disruption.

• An account authorized to operate NTP GPS can create content that runs in another user's browser, breaking isolation between administrative sessions.
• If an administrator opens the affected page, the script can use the administrator's authenticated authority to perform actions, including actions available to an administrator.
• CSRF material and session-authorized operations could be used to access or change resources available to the victim.
• The exact consequences depend on the victim's privileges and the application's browser-side controls. The available evidence does not establish a direct availability impact.

1. For the 26.1 branch, upgrade OPNsense Core to 26.1.11.
2. For the 26.4 branch, upgrade to 26.4.1p1.
3. After upgrading, review the NTP GPS page and stored initcmd values for unapproved HTML or script content.
4. Until an upgrade is possible, temporarily restrict the page-services-ntp-gps privilege to accounts that require it and limit access to the administrative interface. This is interim risk reduction, not a confirmed vendor patch.
5. The available evidence does not document another official workaround. Confirm the status of each release branch against the OPNsense advisory before closing remediation.

• Inventory OPNsense systems and compare each release branch with the confirmed affected and patched boundaries.
• Review accounts holding the page-services-ntp-gps privilege, especially accounts that do not need to edit NTP GPS settings.
• Inspect the stored initcmd value in configuration or through the NTP GPS page for HTML, script content, textarea-closing content, or other unapproved changes.
• Review available audit or access records for GPS configuration changes followed by visits to the page by privileged users. Treat this as precautionary monitoring, not as a vendor-confirmed indicator.
• If logs record API-key creation or privileged authenticated actions, correlate those events with GPS-page access. The available evidence does not define a dedicated log signature or IOC.