{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-107571",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-20T19:27:39.159851Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-20T19:27:48.906Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "hMailServer",
          "repo": "https://gitlab.com/hmailserver/hmailserver",
          "vendor": "Progressive Robot Ltd",
          "versions": [
            {
              "lessThanOrEqual": "6.3.6",
              "status": "affected",
              "version": "6.0.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Found in the hMailServer project\u0027s own security review (Progressive Robot Ltd)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Incorrect default permissions in the Windows installer of Progressive Robot hMailServer 6.0.0 through 6.3.6 allow a local authenticated user to run code as the mail server\u0027s high-privileged accounts when the product is installed in a folder whose permissions are inherited from a writable parent, such as the root of a drive. The installer places the server\u0027s programs in the Bin folder of the program folder and gives neither the program folder nor Bin any permissions of their own, so they inherit the parent\u0027s. Under the default location, Program Files, ordinary users receive only read and execute and the configuration is not affected; but the installer accepts any path without warning, and a program folder at the root of an NTFS volume inherits write access for a broad group - Authenticated Users (Modify) on a Windows client, Users (create files and folders) on Windows Server. A local user without administrator rights can then alter or replace the service program, which runs as LocalSystem or as the service\u0027s virtual account, or the programs an administrator runs elevated from Bin during setup and maintenance, or place a library in Bin that those programs load in place of the system copy, gaining code execution with those privileges. The default Program Files installation is not affected."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "HIGH",
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-276",
              "description": "CWE-276: Incorrect Default Permissions",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-19T15:34:47.493Z",
        "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
        "shortName": "GitLab"
      },
      "references": [
        {
          "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/78"
        },
        {
          "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.7"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "value": "Upgrade to hMailServer 6.3.7. Its hMailServer.exe /ProtectFolders, which setup runs at the end of every server installation and upgrade, gives the program folder, Bin and ControlPanel SYSTEM and the Administrators full control and Users read and execute (where every user could read the folder), nothing inherited, and, where another account owned one of them, makes the Administrators its owner and takes away that folder\u0027s own entries that let others change it; setup also gives a program folder it creates those permissions before it copies anything into it, and hardens, before its files, the existing folder of an installation of the Control Panel alone. 6.3.7 does not yet create a new program folder with those permissions already in place, harden the folder before setup\u0027s own steps on an upgrade, a repair or a server installation into a folder that already existed, refuse a link or junction on the program folder\u0027s path (it is logged), or list the files in Bin and ControlPanel by owner. Before upgrading an affected installation, or until it is upgraded, follow from an elevated Command Prompt the steps in the hMailServer documentation, ServiceAccount.md, \"Before upgrading an installation at a drive\u0027s root\": first note who owns the program folder and what is directly in it (dir /q /a \"\u003cfolder\u003e\") and everything in Bin, ControlPanel, Events, WebAdmin, DBScripts, Addons and Languages (dir /q /s /a); then, for the program folder, then Bin, then ControlPanel, make the Administrators its owner (icacls \"\u003cfolder\u003e\" /setowner *S-1-5-32-544, the folder alone, without /T); take away every entry of the folder\u0027s own but SYSTEM\u0027s, the Administrators\u0027 and deny entries, one account a line (icacls \"\u003cfolder\u003e\" /remove:g: the Users\u0027 and the service\u0027s by their SIDs, the service\u0027s only where the server is installed; the two application package groups by theirs, *S-1-15-2-1 and *S-1-15-2-2; anybody else\u0027s by the name icacls lists; and an entry icacls lists by a SID that names no account with the documentation\u0027s PowerShell line); replace what it inherits (icacls \"\u003cfolder\u003e\" /inheritance:r /grant:r *S-1-5-18:(OI)(CI)F *S-1-5-32-544:(OI)(CI)F *S-1-5-32-545:(OI)(CI)RX); and on Bin and ControlPanel, where the server is installed, give the service account back its read and execute - each icacls line reporting \"Successfully processed 1 files\"; or move the installation under Program Files. Reinstall the programs into a new folder that only the administrators may change, not over the installation, where accounts that are not administrators could sign in while the installation was exposed, where another account made the program folder or could change it before the installation, where anybody but SYSTEM, the Administrators or TrustedInstaller owned the program folder, a file directly in it, or Bin, ControlPanel, Events, WebAdmin, DBScripts, Addons or Languages or anything in them, or where one of the three folders had an entry of its own that let another account change it, or one the steps could not take away: setup leaves in place every file it does not ship, and puts the event script, which the service runs, and the scripts in Addons only where none is there, so read the old event script before copying it. Setup run into a folder without a settings file sets up a new, empty server there, so the settings file and the data go into the new folder first (ServiceAccount.md, \"Reinstalling into a new folder\"): stop the service and run nothing from the old folder, its uninstaller included; copy, not move, the mail, the built-in database\u0027s folder and the settings file into the new folder, the copies kept private; read the copy of the settings file, deleting its AdministratorPassword and each [Directories] line with a path in the old folder; then, with a 32-bit installation\u0027s uninstall entry taken away, run the release\u0027s setup with the new folder; read in the new Control Panel the programs the database\u0027s settings name, make the REST API\u0027s keys again, change each path the database holds into the old folder, and, once nothing names it, delete the old folder by hand."
        }
      ],
      "title": "Incorrect Default Permissions in hMailServer"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
    "assignerShortName": "GitLab",
    "cveId": "CVE-2026-107571",
    "datePublished": "2026-10-19T15:34:47.493Z",
    "dateReserved": "2026-10-08T10:51:20.640Z",
    "dateUpdated": "2026-10-20T19:27:48.906Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}