I work on the ugly bits that nobody loves. These days in infosec, mostly appsec, occasionally (and previously) as a developer.
I'm a Victorian but that doesn't make me old fashioned. I do drink them.
DontSurveil.Me has put together a great explainer on Bill C-22.
Canadians need to pay attention.
Expanding surveillance powers, retaining metadata, and weakening encryption all threaten privacy, free expression, civil liberties, and digital rights.
If we care about privacy, digital rights, and a free society, now is the time to speak up, contact MPs, and push back before this becomes law.
Learn more: https://dontsurveil.me/c22.html
https://github.com/Nightmare-Eclipse/MiniPlasma
another 0day just dropped
CVE-2020-17103 was apparently not patched or the patch was reversed, regardless this the PoC for an LPE in cldflt.sys - Nightmare-Eclipse/MiniPlasma
New, by me: CISA Admin Leaked AWS GovCloud Keys on GitHub
Until this past weekend, a contractor for the Cybersecurity & Infrastructure Security Agency (CISA) maintained a public GitHub repository that exposed credentials to several highly privileged AWS GovCloud accounts and a large number of internal CISA systems. Security experts said the public archive included files detailing how CISA builds, tests and deploys software internally, and that it represents one of the most egregious government data leaks in recent history.
https://krebsonsecurity.com/2026/05/cisa-admin-leaked-aws-govcloud-keys-on-github/
I honestly couldn't care less about VPN providers, but losing secure communications in general would be awful.
If you're #Canadian, write your MP about not supporting C22, at least 41, 5(2) ...
https://www.parl.ca/DocumentViewer/en/45-1/bill/C-22/first-reading
There's apparently another Linux LPE.
DirtyDecrypt, also known as DirtyCBC, is a variant of CopyFail / DirtyFrag / Fragnesia.
I suspect it may be CVE-2026-31635.
Patches (change < to >) were committed on April 8, 2026 and also on April 18, 2026 as beee051f259acd286fed64c32c2b31e6f5097eb5 and e2f1a80d8b1ed6a5ae585a399c2b46500bdcc305
I have not been able to get it to actually work on any Linux distro that I've tried.
(Edit: Fedora and mainline Linux repro fine)
Bill C-22 is quite clearly a bad bill that the Canadian government is digging in it's heels on.
Michael Geist @mgeist covers the latest, which is Signal @signalapp saying they will pull out of Canada if it passes (there is a requirement of retaining metadata for a year -- e.g. phone numbers associated with all messages between them)
Secure messaging service Signal yesterday became the latest company to warn that Bill C-22, the lawful access bill, could force it to leave the Canadian market rather than comply with provisions it says would compromise its end-to-end encryption and create new cybersecurity risks. Signal vice-president Udbhav Tiwari told the Globe and Mail that the company “would rather pull out of the country than be compelled to compromise on the privacy promises we have made to our users.” The comments are part of a steady stream of similar warnings from Apple, Meta, the Canadian Chamber of Commerce, the Cybersecurity Advisors Network, and the chairs of the U.S. House Judiciary and Foreign Affairs Committees. Despite growing concern, the government’s response has been to launch a misleading social media campaign and repeatedly insist that the experts and companies are mistaken.
Apparently exploitation requires CONFIG_RXGK, which most distros don't ship
Except for Fedora.
Or another distro that is running the mainline Linux kernel.
Nightmare-Eclipse has published two new toys to GitHub: GreenPlasma and YellowKey.
TL;DR:
1) GreenPlasma
Here , an unprivileged user can create an arbitrary memory section in an object. While the first time I tried it it hung at the UAC prompt, but subsequent attempts worked to go from low-privileged to creating a \CSRSS_TEST_SECTION object.
It is worth noting that the PoC as it is does not have the bits that would turn it into a true LPE, as that is left as an exercise to the user.
2) YellowKey
This one is a bit hand-wavy to me, But I eventually was able to reproduce it. Via an attached USB drive. I could NOT reproduce it via putting the FsTx directory on the EFI partition. Potentially because the FsTx replay happened before my triggering of Recovery. I was able to reproduce with a USB drive attached.
The target is a TPM-only bitlocker, which is known to be insecure. The use case is that, with physical access, you can access the filesystem with root privileges. Which even TPM-only bitlocker would prevent.
There is a thread on Twitter that claims to have reverse engineered the YellowKey Bitlocker bypass. And it talks about RecoverySimulation.ini and how it skips re-locking a bitlocker drive. The thing about this is:
1) This RecoverySimulation.ini stuff was talked about publicly last year
2) The actual bits in the YellowKey GitHub repo are the contents of an FsTx directory. Which appears to be be related to Transactional NTFS, which uses CLFS under the hood. (The files parse with python's dissect.clfs). Also note that by looking at Windows' fstx.dll, we can see code that explicitly looks for \System Volume Information\FsTx in the FsTxFindSessions() function.
Microsoft themselves have this to say about TxF 😂:
While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers.
And if one looks at the contents of this FsTx directory in the GitHub repo, there are no strings related to RecoverySimulation.ini in it at all. Only of interest is perhaps:\??\C:\Windows\win.ini
and\??\X:\Windows\System32\winpeshl.ini
Where X:\Windows\System32\winpeshl.ini is what controls what WinRE does when it fires up.
But anyway, yes it works.
But what's intriguing to me is: Why can the presence a \System Volume Information\FsTx directory on one volume affect the contents of ANOTHER VOLUME when it's replayed? 🤔
In a normal WinRE session, you have a X:\Windows\System32 directory that has a winpeshl.ini file in it:
Dave Winter
Viss
BrianKrebs
Michael T Babcock
Will Dormann
Boris Mann[LaunchApp]
AppPath=X:\sources\recovery\recenv.exe
However, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the winpeshl.ini file on ANOTHER DRIVE (X:). And we get a cmd.exe prompt, with bitlocker unlocked instead of the expected Windows Recovery environment. While the TPM-only Bitlocker bypass is indeed interesting, I think the buried lede here is that a \System Volume Information\FsTx directory on one volume has the ability to modify the contents of another volume when it is replayed. To me, this in and of itself sounds like a vulnerability.
RE: https://mastodon.social/@campuscodi/116589794228403631
Use this report to help you get approval for accelerated patching processes in your organization.
#cybersecurity
Updated blog post on #CopyFail class #Linux exploits #DirtyFrag #CopyFail2 and #Fragnesia
https://sketchesfromahomelab.com/articles/2026/05/14/Cavalcade_of_Copy_Fails/
Includes updated info and links on
- #AlmaLinux - #DirtyFrag FIXED
- #Debian - #DirtyFrag FIXED
- #Fedora - #DirtyFrag FIXED
- #RHEL - mitigation; no fixes yet
- #RockyLinux - NEW security repo; #DirtyFrag FIXED
- #SUSE Linux - #DirtyFrag FIXED
- #Ubuntu - mitigation; no fixes yet
#cve #cve_2026_43284 #cve_2026_43500 #cve_2026_46300 #linux #security
Brian Clark
[aj]