SunsetHost Hacker News | July 27, 2026 | Certighost Just Handed Your Domain to Anyone With a Badge
Working exploit. Public. July 24. H0j3n and Aniq Fakhrul did not file a quiet disclosure report. They published working proof of concept for an elevation of privilege vulnerability that allows a standard domain user to gain a certificate for a Domain Controller and impersonate it. Not to access it, but to become it. Issue Kerberos tickets for any account of the adversary’s choosing, including domain admin, and have every system in the environment accept those as valid. If you are running Active Directory Certificate Services in anything resembling a default configuration, the clock is already ticking on every domain you administer.
Active Directory Certificate Services has long been a source of headaches; not in the “Microsoft just ships a problematic product” way, but the “security researchers have consistently demonstrated ways to completely undermine a domain due to enrollment misconfigurations” way. Certighost is not something Microsoft will fix with a Tuesday patch. It is a configuration vulnerability, a permissions vulnerability. A hardening vulnerability. Most enterprise IT shops have failed to follow hardening best practices for certificate templates issued for machine authentication, and the working proof of concept is public, today. If one person in your company has access to the domain with an account that meets the minimum requirements for Certificateighost, you are already vulnerable. That person could be a third party vendor or contractor who no longer works at your company. They might be a developer that had their access removed last quarter but used a password from a past breach to reauthenticate. Or they could be your intern who just set their password to “Password123”.
A patch is not the mitigation. The mitigation for Certighost is for your security team to audit certificate enrollment templates for all Certificate Authorities in scope. Look at what accounts have enrollment rights for templates that can issue machine certificates, and ask yourself if any of them could be compromised with the permissions granted. If you do not have those answers immediately, you are already compromised.
SourTrade Taught Browsers to Build the Weapon Themselves
Nobody had to deliver a malicious file to the victim, and that is the point. Sourtrade, the malvertising campaign discovered this week, bypasses many different layers of visibility and detection by not delivering a malicious executable file at all. Instead, it delivers component parts, resources, and assets to the browser that it loads in much the same way a legitimate website would. Runtime bundler Bun.js does the binding work on the victim’s machine, and the resulting binary only exists as a local file on that machine.
This technique breaks many aspects of detection at once. At the network level, the traffic does not trigger any alerts because it looks like innocuous assets being delivered to a browser that is doing its job. There is nothing for hash-based antivirus solutions to compare to known bad files because nothing malicious was delivered. Reputation-based network security tools would not see anything to block, since the delivery mechanism is entirely innocuous. If an enterprise is using perimeter inspection tools to spot malicious files for download, they will miss SourTrade, since it never downloads anything at all. This allows the attack to execute undetected and persist on the victim machine until it is time to exfiltrate data.
What does SourTrade do, exactly? Nothing overtly suspicious, unless you are watching the bundler runtime. Memory analysis, behavioral detection, and endpoint monitoring focused on suspicious activity in the Bun process would be the place to find it.
A Nation-State is Using Telegram for Command and Control and Your Firewall Has No Idea
Researchers this week noted suspicious activity from a nation-state actor targeting organizations in the Middle East, most of which are governmental entities, suggesting they have the resources to withstand a siege. The threat is named TELESHIM, and it is using Telegram’s bot API for command and control, making attribution exceptionally challenging. Most enterprise network security tools are configured to allow Telegram traffic, since it is a legitimate service used by millions of people worldwide. However, TELESHIM is demonstrating that hiding malicious activity inside legitimate encrypted messenger traffic is a viable technique for evading detection. Since Telegram is often placed on a whitelist by network administrators, there is little the average enterprise can do to stop TELESHIM, short of blocking all Telegram traffic, which will certainly break things for users.
The operational impact of TELESHIM is not immediate. It is not a wiper or destructive payload designed to take systems offline and halt operations. TELESHIM is an information-gathering malware that will persist on target networks for an extended period, exfiltrating whatever sensitive information it can find, especially intelligence that has strategic value to the actor behind it. This makes detection based on network anomalies ineffective. Detecting TELESHIM requires endpoint visibility tools that can identify suspicious behavior in Telegram bot API traffic or inspecting traffic for anything out of ordinary for a human user. It is not the kind of detection most enterprise security tools are capable of, and TELESHIM seems to know it.
Fastjson 1.x: No Patch, Unauthenticated RCE, and Active Exploitation Already Underway
Fastjson is a popular JSON parser for Java, utilized by many Spring Boot applications currently in production. ThreatBook and Imperva this week confirmed that Fastjson 1.x has a vulnerability that allows unauthenticated remote code execution, and that it is already being actively exploited.
The mitigation for this vulnerability is complicated and far from ideal. There is no patch, which makes things significantly more difficult. One potential mitigation is to upgrade to Fastjson 2.x, which will resolve the problem, but it requires actual code changes to applications that use it. Another option is to utilize WAF rules described by Threatbook and Imperva, which may provide some protection, but determined attackers will likely circumvent them. The most secure mitigation is to stop using JSON endpoints with the vulnerable versions of Fastjson, depending on how critical they are to your operations. If you cannot tell your engineering team whether any of your applications are affected, you should assume they are until a thorough dependency audit proves otherwise.
GitLab RCE: The Six Week Window Between Patch and Public Exploit Just Closed
GitLab released a patch for a remote code execution vulnerability in self-hosted instances this week, on June 10 th . Researchers at depthfirst published working exploit code for it on the 24th of this month. That means the six week period between the patch release and public availability of the exploit is over for any organization running GitLab 18.11.3 self-hosted with the feature mentioned in the disclosure enabled, and anyone with access to such an instance now has a way to achieve authenticated code execution as the git user.
The security impact of a GitLab compromise is severe and should not be understated. Self-hosted instances tend to hold a wealth of sensitive information, from secrets and credentials to infrastructure-as-code templates that grant access to production systems. Compromise of a GitLab server typically gives the attacker initial access to all projects held on the instance as well as the credentials and deployment tools necessary to interact with production environments. With that said, GitLab is not a high-value target the way other infrastructure is. The vulnerability requires authentication, which may present a challenge to would-be attackers, but GitLab credentials are often obtained via phishing and credential stuffing, making such a barrier effectively meaningless. Any self-hosted instance of GitLab 18.11.3 without the patch from June 10 th applied should be considered compromised, and the logs for any authenticated access in the last six weeks should be reviewed.
GitHub’s Dependabot Cooldown Is Small, Practical, And Directly Responsive to What Happened
GitHub announced a configuration change today, adding a three day cooldown period for Dependabot updates for newly published versions of packages, allowing security researchers and package maintainers to identify and report malicious packages before Dependabot attempts to update a project to it. Three days is not much of a cooldown, but it is the right amount, and the right response to the jscrambler 8.14.0 supply chain attack that happened two weeks ago. The malicious npm package was published and immediately incorporated into downstream projects by automated security tools before it could be identified and removed. Three days would give supply chain defenders and security researchers an opportunity to detect and report it, and Dependabot would wait before attempting to update projects that depend on it, potentially reducing the attack surface of the vulnerability.
The cooldown period could be seen as too short, since it will also delay updates to security patches by three days if they are published in the same way as other versions of a package. However, GitHub made the three day cooldown period configurable at the ecosystem and package level, and it should be possible to keep Dependabot from updating certain packages for longer if needed. It is a reasonable change that does not attempt to solve a complex problem, but addresses a particular set of threats at a particular stage. It prevents the automatic inclusion of malicious packages in downstream projects by shifting the timing of updates slightly, making it possible to detect and block them before they are distributed.
Claude Across Six Enterprise Surfaces With One Security Team Watching One Of Them
Claude is available across six enterprise surfaces: the web interface, the API, the Claude code tooling, Microsoft Office integration, enterprise productivity tools integrations, and custom agentic applications. Each has varying security implications and presents a different vector for exploitation, but a security team only sees one of them at best, the web interface and the API being the only publicly available ones. An agentic Claude deployment with access to production environments and the ability to perform multiple functions without human oversight is an entirely different security concern than Claude running in the browser, answering questions. The same applies to enterprises using Claude code tooling or Office 365 integrations; those with access to Claude in a more privileged position can potentially do much more harm, both to the enterprise and to the outside world, than someone using the web interface. Enterprises using any of these products without visibility into the other surfaces are aware of only a small part of the threat landscape, but they should treat it as if they see all of it, since the risks are very real, and the potential damage is significant. This is not specific to Claude and does not apply to enterprises using only the web interface, it is a general security risk that emerges whenever enterprise AI tools start to see use across an organization faster than security policies and controls can be updated to meet the requirements of the new technology.
The Question About Certighost That Should Not Leave Your Head
Someone in your organization holds a domain account right now. Maybe someone who was laid off four months ago. Maybe someone who had their access revoked but somehow still has it. Maybe someone who is in the building right now. Certighost does not require administrative privileges or any kind of persistent access beyond being authenticated to the domain. A valid user account with access to Certificate Authority enrollment is sufficient to use it, and those kinds of accounts are more common than you think. It is a machine certificate vulnerability, and unless your certificate templates are hardened, which they are not by default, Certighost works flawlessly on your domain.
The proof of concept is public, and the researchers published it today, and the question you need to ask yourself is whether you have audited certificate templates in the past.