Your unattend.xml carries the domain password in clear text

Open the file you install machines with over the network and look for the Password element. What is inside is the account those machines use to join your domain, written as-is. Your technician did not get it wrong. It is literally the example Microsoft publishes in its own documentation.

This comes up because in September the news went round that Microsoft is deprecating Windows Deployment Services, and the deprecation is the least urgent part of it. The two things that have already happened to you have dates, and they are 13 January and 14 April 2026.

Two passwords and two ways of not protecting them

An answer file —the good old unattend.xml— automates installation so nobody has to answer Windows' questions one by one. To do that it needs two credentials: the local administrator of the freshly installed machine, and the account that joins it to the domain. Microsoft documents both, and treats them differently.

The domain one gets no treatment at all. The XML example the official Microsoft-Windows-UnattendedJoin page publishes is this —and the machine account password, two lines below, goes the same way:

<Identification>
   <Credentials>
      <Domain>fabrikam.com</Domain>
      <Password>MyPassword</Password>
      <Username>MyUserName</Username>
   </Credentials>
   <JoinDomain>fabrikam.com</JoinDomain>
   <MachinePassword>ComputerPassword</MachinePassword>
</Identification>

The local administrator one does have an ornament, and the ornament is the interesting part. It carries a child element called PlainText which the documentation describes like this: "Specifies whether the AdministratorPassword is hidden in the unattended installation answer file". Hidden. Not encrypted. With PlainText set to false, the value Microsoft publishes in its own example is this:

<Value>cAB3AEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAUABhAHMAcwB3AG8AcgBkAA==</Value>
<PlainText>false</PlainText>

$ echo 'cAB3AEEAZABt…' | base64 -d | iconv -f UTF-16LE
pwAdministratorPassword

It is base64 of UTF-16 with the setting name glued on the end. The example password is pw. One command, no key, nothing. Whoever sees the file sees the password; all PlainText false buys you is that you do not read it at a glance, and in an audit that counts for exactly zero. We have written before about a field on a user record that turned out to be a credential; this is the same category of problem, except that here the field is called Password and nobody gets to claim surprise.

And until April, that file was served unauthenticated

On 13 January 2026, CVE-2026-0386 was published. The NVD description is a single line: "Improper access control in Windows Deployment Services allows an unauthorized attacker to execute code over an adjacent network". CWE-284, improper access control, 7.5 out of 10 on CVSS 3.1 with vector AV:A/AC:H/PR:N/UI:N and all three impacts —confidentiality, integrity and availability— rated high.

The two letters that matter in that vector are AV:A: adjacent network. It is not exploited from the internet; it is exploited from the same segment. From the meeting-room network socket, from the intern's laptop, or from the flat VLAN where the reception PC and the deployment server live together. And PR:N means no prior privileges are needed: being there is enough. Microsoft's hardening guidance explains the mechanism plainly: "When an unattend.xml file is transmitted over an unauthenticated (insecure) RPC channel, it might expose sensitive data and create a potential risk for credential theft or remote code execution".

An honesty note before going on, because the record says so and it should not be inflated: attack complexity is marked high (AC:H), and the SSVC assessment CISA recorded on 14 January 2026 noted exploitation "none" and automatable "no". This is not a worm. It is a domain credential on an unauthenticated channel, which is a different thing and lasts longer.

The January update mitigated nothing

The fix for this CVE did not arrive as code. It arrived as a checkbox, in two phases three months apart. Microsoft's guidance lists them with their dates and in wording worth reading twice.

Between those two rows there are three months in which a company could have January's Patch Tuesday applied the next day, its inventory green, and the vulnerable behaviour untouched. Phase 1 switched nothing off: it added the switch and a couple of event-log alerts. You have to go and find it, and it lives here:

HKLM\SYSTEM\CurrentControlSet\Services\WdsServer\Providers\WdsImgSrv\Unattend
    AllowHandsFreeFunctionality   0x00000000  blocks unauthenticated access
    AllowHandsFreeFunctionality   0x00000001  permits insecure hands-free

We wrote this recently about something else: a patching policy that can only say "applied" or "pending" has no box for this. "Updated" and "mitigated" are two different claims, and in January 2026 only one of them was true. If your answer to an audit is the WSUS report, in this case the report says yes and the machine says no.

That same phase 1 added two event-log entries, and they are the documentary evidence of what state each server is in. If the block is active, the event reads: "Warning: Unattend file request was made over an insecure connection. Windows Deployment Services has blocked the request to keep the system secure". If somebody turned the feature back on, the server writes the opposite: "Error: This system is using insecure settings for Windows Deployment Services". Which means the answer to "where do we stand?" has been writing itself for months on a machine hardly anyone logs into. With one caveat worth stating so the log does not give false comfort: those entries are written when an answer-file request comes in, so an empty log does not prove the server is fine, only that nothing has asked it for anything.

The symptom arrives months later and looks nothing like the cause

On 14 April the default flipped across all supported platforms. And from there the usual thing about default changes happens: nobody notices on the day, because nobody rebuilds servers on a Patch Tuesday for fun. You notice weeks or months later, when somebody has to rebuild a machine and the deployment that used to run itself stops running itself. So much time goes by between cause and symptom that the connection gets lost, and the technician starts hunting for what he broke.

There is a second symptom, separate from this one and worth not mixing up, because it is even more misleading. If your WDS runs on Windows Server 2025 and you boot with the boot.wim from the installation media, the documentation warns you may get this: "A media driver your computer needs is missing. This could be a DVD, USB or Hard disk driver". And it adds, in so many words, that "an error message is expected since using boot.wim on WDS running on Windows Server 2025 isn't supported". The message talks about a missing driver. The cause is that the workflow is no longer supported. Believe the message and you can spend an afternoon injecting network and storage drivers into an image that was never going to boot.

What the September notice says, and what it does not

The official sentence, in documentation updated on 18 September 2026, is this: "Windows Deployment Services (WDS) is deprecated beginning with the OS version following Windows Server 2025. This includes the inbox WDS role, WDS services, management tools and interfaces, and WDS-provided Preboot Execution Environment (PXE) boot functionality". It is a future deprecation: it starts with the OS version after Windows Server 2025. On Windows Server 2025 and earlier, the role remains supported per its lifecycle.

We misread it ourselves on the first morning, so two things are worth separating. That sentence does include WDS PXE boot, but it is talking about the Windows Server version after 2025. Today WDS PXE boot still works, and the same page says so about the current change, in a section titled "Not affected": "This change doesn't affect WDS PXE boot. WDS can still be used to PXE boot devices with custom boot images". What is already blocked is using the installation media's boot.wim as the boot image and running Setup in WDS mode. Workflows that use a custom image —the ones many companies build with MDT or Configuration Manager— are not touched by that particular change, even though they do sit inside the perimeter of the future deprecation.

Where it does hurt is at the new end of the estate: for Windows 11, the documentation table reads "Not supported, blocked" with any media boot.wim, including Windows 11's own, and the summary finishes with "an end to end deployment of Windows 11 using only WDS can't be performed". For Windows Server 2022 the workflow is still alive with a dismissible warning; for Windows 10 and Windows Server 2019 nothing changes. So: the WDS in a lot of small firms still installs the old thing and does not install the new one, which is the worst way a tool can age, because it does not fall over. It goes halfway, and the date never gets set.

Switching the feature off does not rotate the password

This is the part that genuinely worries us, and we have not found it in the coverage we have read these past days nor in Microsoft's own guidance, which stops at switching the feature off and planning the migration to other tools. Setting that registry value to zero blocks unauthenticated access to the unattend.xml. It does not delete the file, does not move it and, above all, does not change the password inside it. If that account was exposed —and if your WDS spent years serving hands-free deployments on a flat network, the question is not whether it was reachable but for how long— it is still valid today, with the same permissions it had.

And that account's permissions are the second problem. Joining machines to a domain can be delegated with a very specific permission over one organisational unit. In the estates we find when we take over maintaining an infrastructure, that account is usually a domain administrator, because that is what makes the deployment work first time on the day it is built and nobody touches it again. A readable file and an oversized account, together, make a path.

What we would look at this week

On that fourth point it is worth adding a fact that bounds the conversation: Microsoft points to Configuration Manager as the recommended alternative, and the hardening guidance additionally points to cloud solutions such as Autopilot. It also clarifies, and this matters for knowing what we are talking about, that "this vulnerability does not impact Microsoft Configuration Manager. The issue applies only to native Windows Deployment Services (WDS) scenarios where an Unattend.xml file is referenced". Put another way: if you already run Configuration Manager, this particular hole was not yours. If you have a bare WDS that boots machines with an unattend.xml, it was.

If your recovery starts on the network

There is one place where this stops being an annoyance and turns into a number: the recovery plan. Plenty of return-to-service procedures start with "boot the machine over the network and reinstall". If that first step depends on a role with an announced expiry date and on a workflow that no longer covers half the estate, the recovery time you have written down is not the one you will measure on the bad day. We have already covered how to work out an RTO and an RPO without the fluff; this is exactly the kind of dependency that does not show up in the spreadsheet and does show up at three in the morning.

And the conflict of interest up front, as always: everyWAN lives off IT maintenance and managed services, so putting this in order is something we invoice. The verifiable part of this post is not: anyone can check that registry value this afternoon, the answer files are on a share in your own building, and the sentences we have quoted are linked at the end so you can read them at the source rather than in our rendering.

Sources (verified on 5 October 2026): description, publication date, CWE, CVSS score and vector and CISA's SSVC assessment — NVD, CVE-2026-0386 (published 13 January 2026). The unauthenticated RPC channel mechanism, phases 1 and 2 with their dates, the registry path and values, the two event-log entries, and the sentences about Configuration Manager and Autopilot — Microsoft hardening guidance related to CVE-2026-0386 (last updated 14 April 2026). The role deprecation sentence, the "Not affected" section, the supported-scenario table, the missing-driver error message and the April 2026 sentence — official WDS boot.wim support documentation (updated 18 September 2026). XML examples and the description of the PlainText element — official pages for AdministratorPassword and UnattendedJoin / Credentials. The decoding of the example value is ours, performed on the literal value that page publishes. Cover photograph: "A front-facing shot of a black wall-mounted network rack…", by Mohammed Kateregga, via the WordPress photo directory and Openverse, public domain (CC0).