CVE-2025-66509 is a pre-authentication code execution chain in LaraDashboard 2.3.0 and earlier. The password reset flow trusts the Host header, so an administrator's reset token can be sent to an attacker's server, and module installation then runs PHP code. The record scores it 9.8 critical.
What's affected
- Product: LaraDashboard, a Laravel starter application (Composer package laradashboard/laradashboard).
- Affected: 2.3.0 and earlier.
- Fixed: the advisory lists patched versions as None and says the issue is patched in commit cc42f9c. The record links the same commit. Check the project releases for a tagged version that contains it.
Severity differs by source. The record scores 9.8 (critical). The GitHub advisory rates it High. Either way, the advisory describes the full chain as one click and pre-authentication, so treat it as urgent for any internet facing install.
How to check if you're exposed
Find the version or commit you deployed.
git -C /path/to/app describe --tags
grep -n "laradashboard" composer.json
If it is 2.3.0 or earlier and does not include the fix commit, you are exposed. Then check whether the application is reachable from the internet, and whether your web server or proxy passes any Host header through to the application unchecked.
What to do now
- Update to a release that contains commit cc42f9c, or apply that change to your copy.
- Make sure the application only answers to your real host names. At the web server, reject requests with unexpected Host values. In Laravel, the trusted hosts middleware is the usual way to do this.
- Set your application URL explicitly so password reset links are not built from the request.
- Review who has the rights to install modules, and review installed modules for code you did not add.
- Look at password reset requests in your logs and mail records for unexpected ones around the time you were exposed.
- Scan your Composer dependencies as well. Paste your manifests into the free in-browser scan at gold.safeguard.sh/scan to see which of your dependencies carry this CVE, and use reachability analysis to separate the services that actually call the affected code from the ones that only list the package.
Why it matters
There are two weaknesses. The first is that the password reset link is built from the Host header of the request. A caller who controls that header can make the link point at a server they run, so the reset token goes to them. The second is that installing a module runs its code at once through the service provider boot method. The record tags the issue CWE-284, improper access control.
Each flaw is modest alone. Chained, they take an unauthenticated visitor to code execution on the server. Host header trust is a common mistake in web frameworks, and password resets are a favorite target for it. The record does not list exploitation in the wild, and the CVE is not on CISA KEV.
Quick check
Who can start this attack?
Per the advisory, an unauthenticated attacker, using the Host header flaw to take over the administrator account and then the module install feature.
Is there a tagged fix?
The advisory lists none but names a commit. Verify your build includes it.
Sources
Last reviewed: 18 October 2026.
