FreePBX is an open source IP PBX. Prior to 16.0.22 and 17.0.5, the Dashboard module's getcontent AJAX handler includes PHP files based on user-supplied input without path sanitization. The $_REQUEST['rawname'] parameter is concatenated into an include() call with a .class.php suffix, allowing path traversal via ../ sequences to include arbitrary .class.php files from the filesystem. The included file's PHP code executes before the subsequent class instantiation error occurs. This vulnerability is fixed in 16.0.22 and 17.0.5.

A stored Cross-Site Scripting (XSS) vulnerability exists in the project selector component of Mautic 7. When rendering selection menus for associating projects with system entities, the application fails to sanitize project names returned via AJAX before injecting them into the DOM as option fields. An authenticated user with permissions to create projects can exploit this to store a malicious script payload in the project's name. When another administrative user subsequently opens an entity editor containing the project selector, the injected script executes within the context of their active browser session. This could allow an attacker to hijack the session, perform unauthorized state coordination, or access organizational data within the dashboard.

A path traversal vulnerability was identified in Kibana's dashboard management functionality. An authenticated user with limited permissions could create a dashboard with a specially crafted identifier. When an administrator subsequently attempts to delete this dashboard through the Kibana interface, the deletion request is redirected to an unintended internal endpoint, potentially resulting in the unauthorized deletion of user accounts or other resources. Exploitation requires an administrator to perform a delete action on the maliciously crafted dashboard object.

elastic

In the Linux kernel, the following vulnerability has been resolved: spi: microchip-core-qspi: control built-in cs manually The coreQSPI IP supports only a single chip select, which is automagically operated by the hardware - set low when the transmit buffer first gets written to and set high when the number of bytes written to the TOTALBYTES field of the FRAMES register have been sent on the bus. Additional devices must use GPIOs for their chip selects. It was reported to me that if there are two devices attached to this QSPI controller that the in-built chip select is set low while linux tries to access the device attached to the GPIO. This went undetected as the boards that connected multiple devices to the SPI controller all exclusively used GPIOs for chip selects, not relying on the built-in chip select at all. It turns out that this was because the built-in chip select, when controlled automagically, is set low when active and high when inactive, thereby ruling out its use for active-high devices or devices that need to transmit with the chip select disabled. Modify the driver so that it controls chip select directly, retaining the behaviour for mem_ops of setting the chip select active for the entire duration of the transfer in the exec_op callback. For regular transfers, implement the set_cs callback for the core to use. As part of this, the existing setup callback, mchp_coreqspi_setup_op(), is removed. Modifying the CLKIDLE field is not safe to do during operation when there are multiple devices, so this code is removed entirely. Setting the MASTER and ENABLE fields is something that can be done once at probe, it doesn't need to be re-run for each device. Instead the new setup callback sets the built-in chip select to its inactive state for active-low devices, as the reset value of the chip select in software controlled mode is low.

linux

The Login No Captcha reCAPTCHA plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the `$_SERVER['PHP_SELF']` superglobal in all versions up to, and including, 1.8.0. This is due to the `authenticate()` function storing the unsanitized output of `basename($_SERVER['PHP_SELF'])` in the `login_nocaptcha_error` WordPress option when a login attempt is made from a non-standard login page (e.g., xmlrpc.php). The `admin_notices()` function then echoes this stored value directly into the admin dashboard HTML without escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts that execute when an administrator with a whitelisted IP address visits the WordPress dashboard within 30 seconds of the attack.

Budibase is an open-source low-code platform. Prior to 3.38.1, the POST /api/global/users/onboard endpoint is protected by workspaceBuilderOrAdmin middleware, allowing any user with builder permissions to access it. When SMTP email is not configured (the default for self-hosted Budibase instances), this endpoint bypasses the admin-restricted invite flow and directly creates users via bulkCreate, accepting arbitrary admin and builder role assignments from the request body. A builder-level user can create a new global admin account and receive the generated password in the response, achieving full privilege escalation. This vulnerability is fixed in 3.38.1.

Cinny is a Matrix client. Prior to 4.10.3, A remote authenticated attacker who shares a room with a victim and has permissions to create room emotes (for example in a DM) can cause the victim's client to send their Matrix access token to an attacker-controlled server. This occurs when the victim opens the emoji or sticker picker for the room containing a malicious emote pack. This is caused by an incorrect fallback in EmojiBoard that uses untrusted pack.meta.avatar (user-controlled) without converting/validating it as an MXC URL, allowing arbitrary HTTP(S) URLs to be used. Also, the service worker attaching the user's Authorization bearer token to all outbound GET requests whose URL contains /_matrix/client/v1/media/download or /_matrix/client/v1/media/thumbnail without verifying the request host matches the configured homeserver origin. An attacker-controlled URL containing those path fragments and permissive CORS will receive the victim's Authorization header (access token). This vulnerability is fixed in 4.10.3.

An low privileged remote attacker can exploit an unauthenticated SQL Injection vulnerability in the dashboard view due to improper neutralization of special elements in a SQL SELECT command. This can result in a total loss of confidentiality.

An low privileged remote attacker can exploit an unauthenticated SQL Injection vulnerability in the dash_layout.php files saveDashboardLayout function due to improper neutralization of special elements in a SQL INSERT command allowing for reading the whole database and inserting entries into a non critical table. This can result in a total loss of confidentiality and some loss of integrity.

An low privileged remote attacker can exploit an unauthenticated SQL Injection vulnerability in the dash.php files saveDashboardLayout function due to improper neutralization of special elements in a SQL INSERT command allowing for reading the whole database and inserting entries into a non critical table. This can result in a total loss of confidentiality and some loss of integrity.

Uncontrolled Resource Consumption vulnerability in oban-bg oban_web ('Elixir.Oban.Web.CronExpr' modules) allows memory exhaustion via unbounded cron range expansion. An attacker with access to schedule cron jobs can submit a malicious cron expression such as "0 0 1-100000000 * *". When a user with dashboard access views the cron job list, 'Elixir.Oban.Web.CronExpr':describe/1 is called to render the expression. parse_range/1 parses both range endpoints via Integer.parse/1 with no bounds check, and the downstream helpers expand_dom_parts/1 and expand_dow_parts/1 materialise the range eagerly via Enum.to_list/1, causing allocation of ~2.4 GB and stalling or crashing the BEAM node. A sibling helper extract_dom_values already validates range bounds, but the expansion helpers do not. This issue affects oban_web: from 2.12.0 before 2.12.5.

Chatwoot is a customer engagement suite. From 2.14.0 to before 4.13.0, a Pre-Account Takeover (Pre-ATO) vulnerability existed in Chatwoot's authentication flow. Because email confirmation was not enforced before an account became usable, an attacker could pre-register an email address they did not own and set a password. If the legitimate owner of that email later signed in to Chatwoot using Google OAuth (or another OmniAuth provider), the OAuth flow silently confirmed the existing account without invalidating the attacker's pre-set credentials. The attacker could then continue to log in with the password they had originally chosen and access any data the victim subsequently entered into the dashboard, including PII, API keys, and other sensitive information. This vulnerability is fixed in 4.13.0.

A weakness has been identified in ThingsBoard up to 4.3.1.1. Affected by this vulnerability is the function getGatewayDockerComposeFile of the file /api/v1/provision of the component YAML Handler. This manipulation causes code injection. It is possible to initiate the attack remotely. The attack's complexity is rated as high. The exploitation appears to be difficult. The project was informed of the problem early through a pull request but has not reacted yet.

A vulnerability has been found in sambitraj STUDENT-MANAGEMENT-SYSTEM up to 56ba287f2e9031523ccb4244cb6e3fe530e4e5d5. The affected element is an unknown function of the component Dashboard. Such manipulation leads to improper access controls. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. This product operates on a rolling release basis, ensuring continuous delivery. Consequently, there are no version details for either affected or updated releases. Multiple endpoints are affected. The project was informed of the problem early through an issue report but has not responded yet.

A security flaw has been discovered in NousResearch hermes-agent 2026.4.23. Affected is the function _discover_dashboard_plugins of the file hermes_cli/web_server.py of the component CLI web-dashboard Interface. Performing a manipulation of the argument HERMES_ENABLE_PROJECT_PLUGINS results in incorrect comparison. The attack is only possible with local access. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

TypeBot is a chatbot builder tool. In versions 3.16.0 and prior, the WhatsApp Cloud API webhook endpoint (POST /v1/workspaces/{workspaceId}/whatsapp/{credentialsId}/webhook) does not verify the x-hub-signature-256 HMAC signature included by Meta in every webhook delivery. The webhook URL exposes both workspaceId and credentialsId as path parameters, which are logged in web server access logs, visible in Meta's webhook configuration dashboard, and potentially shared when configuring integrations. This allows any unauthenticated attacker to send spoofed webhook messages to trigger bot flows, consume API resources, and interact with external services using the workspace owner's credentials. The issue has been fixed in version 3.17.0.

Mattermost versions 11.6.x <= 11.6.0, 11.5.x <= 11.5.3, 11.4.x <= 11.4.4, 10.11.x <= 10.11.14 fail to validate file ownership and access control, which allows an authenticated user to access and download files belonging to other users or teams via crafted Boards API requests using valid file IDs.. Mattermost Advisory ID: MMSA-2026-00620

mattermost

Concrete CMS 9.5.0 and below is vulnerable to Reflected XSS in Legacy Pagination via HTML attribute injection. Concrete\Core\Legacy\Pagination builds pagination links by raw-interpolating its $URL field into href="" (<a href="{$linkURL}" …>). Any authenticated admin or report viewer with access to `/dashboard/reports/forms/legacy` who clicks the crafted URL fires the payload in their session. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 6.0 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori (Tenzai) for reporting

concretecms

Concrete CMS 9.5.0 and below is vulnerable to IDOR in AddMessage/UpdateMessage via attachments[] parameter which can lead to file permission bypass. The `AddMessage` and `UpdateMessage` conversation controllers accept user-supplied file attachment IDs and load files directly via `$em->find(File::class, $attachmentID)` without checking per-file permissions (`canViewFile()`). A user who can post in any conversation can reference any file in the CMS file manager by its sequential ID, effectively bypassing the file permission system.  The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 2.3 with a vector CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Tristan Mandani for reporting. if a site truly has private files, the owner should set up a private storage location https://documentation.concretecms.org/user-guide/editors-reference/dashboard/system-and-maintenance/files/file-storage-locations outside of the webroot so that permissions can be checked on view as well. That way, even if a authorized user attaches a file, or otherwise links to it, unauthorized users won't be able to view the file.

concretecms

Concrete CMS 9.5.0 and below emits a CSRF token in the local_available_update.php view ($token->output('do_update')) but the corresponding do_update() method in concrete/controllers/single_page/dashboard/system/update/update.php never calls $this->token->validate('do_update'). The form is rendered as a POST form, meaning the token reaches the browser, but because the controller discards it without verification, an attacker can craft a cross-site POST that triggers a core CMS update to an attacker-specified version string.  In order to be vulnerable, theictim must be passing canUpgrade()anda valid update version must be present under DIR_CORE_UPDATES. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.5 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks https://github.com/maru1009 for reporting.

concretecms

Concrete CMS 9.5.0 and below does not validate a CSRF token before processing requests to /dashboard/extend/update/prepare_remote_upgrade/<remoteMPID>. An attacker who controls the remote package returned for a known marketplace item ID can overwrite the package PHP on disk and force its upgrade() method to execute in a single browser navigation. This results in remote code execution as the web server user.   In order to be vulnerable, the victim must be passing canInstallPackages, victim site must be connected to the Concrete marketplace; and the attacker controls the package returned for a marketplace item ID already installed on the victim site. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.5 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks https://github.com/maru1009 for reporting.

concretecms

Concrete CMS 9.5.0 and below contains a CSRF vulnerability in the install_package() method of concrete/controllers/single_page/dashboard/extend/install.php.  An attacker who can cause an authenticated administrator to visit a crafted page,  and who has placed or caused a package to be present under DIR_PACKAGES/<handle>/, can force the installation of that package without any CSRF protection. Package installation executes the package controller's install() method as the web server user, enabling remote code execution.  In order to be vulnerable, the victim must be passing canInstallPackages. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.5 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks  https://github.com/maru1009  for reporting.

concretecms