GHSA-4F9R-X588-PP2H
Vulnerability from github – Published: 2026-03-30 19:29 – Updated: 2026-03-30 19:29Summary
Fleet contained an issue in the user invitation flow where the email address provided during invite acceptance was not validated against the email address associated with the invite. An attacker who obtained a valid invite token could create an account under an arbitrary email address while inheriting the role granted by the invite, including global admin.
Impact
If an attacker gains access to a valid invite token, they can create a Fleet user account with an email address of their choosing while inheriting the invite’s assigned role and team memberships.
This issue:
- Requires possession of a valid invite token
- Does not bypass authentication controls beyond invite-based account creation
- Does not expose data without successful account creation
Workarounds
If upgrading immediately is not possible:
- Treat invite links as sensitive credentials and avoid sharing them in public or semi-public channels (e.g., Slack, Teams).
- Revoke and reissue invites if there is any concern that an invite link may have been exposed.
- Prefer issuing invites with the minimum required privileges and elevating roles after account creation when appropriate.
For more information
If there are any questions or comments about this advisory:
Send an email to security@fleetdm.com
Credits
Fleet thanks @fuzzztf for responsibly reporting this issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/fleetdm/fleet/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.81.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34389"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-30T19:29:13Z",
"nvd_published_at": "2026-03-27T20:16:35Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nFleet contained an issue in the user invitation flow where the email address provided during invite acceptance was not validated against the email address associated with the invite. An attacker who obtained a valid invite token could create an account under an arbitrary email address while inheriting the role granted by the invite, including global admin.\n\n### Impact\n\nIf an attacker gains access to a valid invite token, they can create a Fleet user account with an email address of their choosing while inheriting the invite\u2019s assigned role and team memberships.\n\nThis issue:\n\n- Requires possession of a valid invite token\n- Does not bypass authentication controls beyond invite-based account creation\n- Does not expose data without successful account creation\n\n### Workarounds\n\nIf upgrading immediately is not possible:\n\n- Treat invite links as sensitive credentials and avoid sharing them in public or semi-public channels (e.g., Slack, Teams).\n- Revoke and reissue invites if there is any concern that an invite link may have been exposed.\n- Prefer issuing invites with the minimum required privileges and elevating roles after account creation when appropriate.\n\n### For more information\n\nIf there are any questions or comments about this advisory:\n\nSend an email to [security@fleetdm.com](mailto:security@fleetdm.com)\n\n### Credits\n\nFleet thanks @fuzzztf for responsibly reporting this issue.",
"id": "GHSA-4f9r-x588-pp2h",
"modified": "2026-03-30T19:29:13Z",
"published": "2026-03-30T19:29:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fleetdm/fleet/security/advisories/GHSA-4f9r-x588-pp2h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34389"
},
{
"type": "PACKAGE",
"url": "https://github.com/fleetdm/fleet"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Fleet\u0027s user account creation via invite does not enforce invited email address"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.