Submit #986186: UVdesk community-skeleton 1.1.8 Missing Authorization
| Title | UVdesk community-skeleton 1.1.8 Missing Authorization |
|---|---|
| Description | The installation wizard endpoints in uvdesk/community-skeleton (registered under /wizard/xhr/* in src/Resources/config/routes.yaml) remain reachable by unauthenticated clients after the application is already installed. There is no "already installed" check on these routes, and config/packages/security.yaml's access_control list has no entry for the /wizard path, so requests fall through to the catch-all "customer" firewall which permits anonymous access. This exposes three unauthenticated primitives in src/Controller/ConfigureHelpdesk.php: 1) SSRF via verifyDatabaseCredentials() (line ~148): attacker-supplied serverName/serverPort are used directly to open a real Doctrine\DBAL\DriverManager connection, regardless of APP_ENV. The endpoint returns different messages depending on whether the target host:port was reachable, giving an unauthenticated port-scan/service-discovery oracle against internal network hosts. 2) Unauthenticated rewrite of the live .env DATABASE_URL via updateConfigurationsXHR() (line ~227), which invokes the "uvdesk_wizard:env:update" console command. After seeding $_SESSION['DB_CONFIG'] via primitive 1, an unauthenticated request can rewrite the application's live .env file to point at an attacker-controlled database. Verified live: the Doctrine debug log shows subsequent requests actually connecting with "dbname":"attacker_db", confirming the running application's persistent storage was fully redirected -- a persistent denial of service, or account takeover if the attacker's database contains attacker-controlled credentials. This primitive is gated by src/Console/EnvironmentVariables.php requiring APP_ENV=dev; however APP_ENV=dev is the DEFAULT value shipped in .env and is not changed by the installer, so it applies to a standard, unmodified installation. 3) Unauthenticated database mutation via populateDatabaseEntitiesXHR() (line ~322, running "doctrine:fixtures:load --append" with no guard at all, regardless of APP_ENV) and migrateDatabaseSchemaXHR() (line ~310, running "uvdesk_wizard:database:migrate"). Verified live: an unauthenticated POST to /wizard/xhr/load/entities caused real rows to be written to the database (uv_ticket_status count went from 0 to 6). Reproduced against a local Docker deployment of the official v1.1.8 release (git tag v1.1.8, published 2025-09-19), not against any third party's production instance. Negative control performed: with APP_ENV=prod, the identical request sequence for primitive 2 correctly fails ({"success":false}) and the .env file is not modified, confirming the defect is the default APP_ENV=dev configuration combined with the missing install-lock, not an environment artifact. Vendor was notified via [email protected] prior to this submission, per their disclosed security contact (no SECURITY.md or GitHub private vulnerability reporting is configured for this repository). |
| Source | ⚠️ https:/ |
| User | Ibrohimm (UID 101322) |
| Submission | 09/17/2026 07:46 (1 month ago) |
| Moderation | 10/19/2026 14:32 (1 month later) |
| Status | Duplicate |
| VulDB entry | 406172 [UVdesk Community Skeleton up to 1.1.8 Installation Wizard improper authentication] |
| Points | 0 |