CVE-2026-105129: LaraDashboard Information Disclosure Flaw

CVE-2026-105129 Overview

CVE-2026-105129 is an incorrect authorization vulnerability [CWE-863] in LaraDashboard versions before 1.4.8. The flaw allows authenticated users holding only the low-privilege settings.view permission to retrieve stored secrets through the settings API. Attackers can issue GET /api/settings or GET /api/settings/{option_name} requests to read plaintext AI provider API keys, mail credentials, passwords, and tokens. The vendor addressed the issue in LaraDashboard v1.4.8 through pull request #340 and commit 532a10e.

Critical Impact
Any authenticated user with the settings.view permission can exfiltrate plaintext secrets, including third-party API keys and SMTP credentials, directly from the settings API without additional privilege checks.

Affected Products

LaraDashboard versions prior to 1.4.8
LaraDashboard v1.4.2 (confirmed vulnerable via referenced source code)
LaraDashboard deployments exposing /api/settings endpoints to authenticated users

Discovery Timeline

2026-10-04 - CVE-2026-105129 published to NVD
2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-105129

Vulnerability Analysis

The vulnerability resides in LaraDashboard's settings API layer, specifically in app/Http/Controllers/Api/SettingController.php and app/Http/Resources/SettingResource.php. The controller authorizes access using the broad settings.view permission enforced by SettingPolicy, then returns raw option values from the settings table. Because the resource serializer does not filter sensitive option names, every stored value is returned in plaintext.

LaraDashboard stores integration secrets as settings records. These include AI provider API keys, mail transport credentials, and authentication tokens used by scheduled jobs. A low-privilege operator who should only view non-sensitive configuration can enumerate the full secret inventory in a single API call.

Root Cause

The root cause is a missing differentiation between viewing general settings and viewing secrets. SettingPolicy grants read access based solely on settings.view, and SettingResource emits all option_value fields without a deny-list for secret keys. There is no field-level authorization or redaction between the database and the API response.

Attack Vector

Exploitation requires network access to the LaraDashboard API and a valid session with the settings.view permission. The attacker sends an authenticated GET /api/settings request to list all options, or targets specific keys through GET /api/settings/{option_name}. The response contains plaintext secrets that can be used to pivot to AI provider accounts, mail infrastructure, or integrated services.

php

// Patch excerpt from app/Enums/Hooks/SettingFilterHook.php
     case SETTINGS_TABS = 'filter.settings.tabs';
     case SETTINGS_RESTRICTED_FIELDS = 'filter.settings.restricted_fields';
 
+    /** @param list<string> $keys Additional option_name values treated as secrets */
+    case SETTINGS_SENSITIVE_KEYS = 'filter.settings.sensitive_keys';
+
+    /** @param list<string> $keys Option names omitted from settings API index/show */
+    case SETTINGS_HIDDEN_FROM_API_KEYS = 'filter.settings.hidden_from_api_keys';
+
     // UI Hooks - General tab
     case SETTINGS_GENERAL_TAB_BEFORE_SECTION_START = 'filter.settings.general_tab_before_section_start';
     case SETTINGS_GENERAL_TAB_BEFORE_SECTION_END = 'filter.settings.general_tab_before_section_end';

Source: GitHub Commit 532a10e. The patch introduces explicit enumerations for sensitive keys and keys to omit from the settings API, enabling server-side filtering before serialization.

Detection Methods for CVE-2026-105129

Indicators of Compromise

Authenticated GET /api/settings or GET /api/settings/{option_name} requests from accounts that normally do not interact with configuration endpoints.
API responses containing fields matching secret patterns such as *_api_key, mail_password, smtp_password, or *_token.
Outbound traffic to AI provider APIs or SMTP relays from new or unexpected source IPs shortly after settings API access.

Detection Strategies

Review LaraDashboard application logs for settings.index and settings.show controller actions executed by users holding only settings.view.
Correlate web server access logs with user permission assignments to identify low-privilege accounts querying /api/settings endpoints.
Alert on API responses from LaraDashboard whose payload length or field count is anomalously large for the invoking user role.

Monitoring Recommendations

Enable verbose audit logging on the LaraDashboard settings module and forward events to a centralized log platform.
Monitor usage of credentials associated with configured AI providers and mail services for authentication from unexpected locations.
Track role and permission changes that grant settings.view to new users or groups.

How to Mitigate CVE-2026-105129

Immediate Actions Required

Upgrade LaraDashboard to version 1.4.8 or later, which contains the authorization and serialization fixes delivered in pull request #340.
Rotate all secrets previously stored in LaraDashboard settings, including AI provider API keys, SMTP credentials, and integration tokens.
Audit accounts holding the settings.view permission and revoke it where not required.

Patch Information

The fix is included in GitHub Release v1.4.8 via GitHub Pull Request #340 and commit 532a10e. The patch adds SETTINGS_SENSITIVE_KEYS and SETTINGS_HIDDEN_FROM_API_KEYS filter hooks and routes email settings through a new getAllSettingsForApi() method that excludes sensitive values. See the GitHub Security Advisory GHSA-xgmw-7ppx-v7hq and the VulnCheck Advisory on Laradashboard for full details.

Workarounds

Restrict network access to /api/settings and /api/settings/{option_name} to administrator IP ranges using a reverse proxy or web application firewall rule until the upgrade is applied.
Temporarily remove the settings.view permission from all non-administrator roles.
Move high-value secrets out of LaraDashboard settings storage into environment variables or an external secret manager where feasible.

bash

# Example reverse proxy rule to restrict settings API to admin network
location ~ ^/api/settings {
    allow 10.0.0.0/24;    # admin management subnet
    deny all;
    proxy_pass http://laradashboard_backend;
}