Claude Code settings left secrets in public GitHub files and 5 more

What people are saying

A post on r/msp warned managed service providers (MSPs) who use the vendor MSP Process to check their tenants. The vendor posted the pinned comment, which thanks Huntress and Petra for their help. Several security vendors joined the thread to say they were checking their own customers. In our reading, the early framing of an MSP being breached is off: the compromised party is a software vendor whose apps sit inside MSP tenants.

What holds up

MSP Process called it a very complex attack that it is still reviewing. It said the attack did not reach all of its partners and that it had contacted affected partners by email and text message. The vendor added that users who did not get an email are unlikely to have been affected.

Huntress said it saw successful malicious token grants in 47 tenants during the attack window, with one tenant showing significant post-compromise activity. By Huntress's account, stolen secrets for partner-registered MSP Process apps were used against MSP partners' own tenants, and most saw only a quick test sign-in. In one MSP's tenant the attacker worked hands on for about five hours.

Huntress said all successful access fell inside the vendor's stated window of November 7, 09:56 to 14:40, with failed attempts against the same targets on November 6. Attempts to use stolen admin refresh tokens all failed, according to Huntress. In our reading, the core event is established by the vendor itself. How the secrets were taken and how far the damage reached into downstream clients remain open.

Inside the threads

The largest camp treated this as urgent, with one commenter advising MSP Process users to "treat this as an active incident today, not a ticket for Monday." Practitioners stressed that the app's Authenticator permissions let it add credentials to other apps and grant itself more access. One tooling founder warned that a credential added inside a client tenant can still sign in after the partner-side secret is deleted. A commenter posted a login-traffic figure that another misread as the attacker making up a third of traffic; the original poster then corrected the statistic. Some users said they never received the vendor's email, and one guessed it went only to those directly impacted. A side argument broke out over whether compliance certifications mean anything after an incident like this.

Our take

We think the lesson here is about standing third-party app access, not about one vendor. A multi-tenant app with broad directory permissions is a privileged identity, and most organizations do not review it like one. The scale so far looks contained, and in our reading the alarm over traffic share came from a misread number. What is underrated is cleanup: deleting a secret does not undo credentials an attacker may have planted downstream. If your MSP uses this vendor, your tenant may be one hop from the incident even if your MSP was not hands-on compromised. Treat MSP-installed apps as part of your third-party risk program.

What to do

• Ask your MSP whether it uses MSP Process apps and whether it received the vendor's notice.
• Inventory third-party apps holding high-privilege directory permissions and remove any without a current business owner.
• Export identity audit and sign-in logs for November 6 and 7 now, before retention limits remove them.

What people are saying

A Science feature reports that construction and mining companies are using fatigue-monitoring devices to improve safety, while critics say the devices threaten workers' privacy. The story appeared in the print edition of Science and was produced with the Pulitzer Center's AI Accountability Network. On Reddit, it drew a thread in r/privacy where one commenter warned it would increase workplace discrimination.

What holds up

Science reports that helmets made by Huanao Security (Beijing) Technology contain multiple sensors that keep tabs on the workers wearing them. The helmets, branded NeuroHua, have been used at dozens of high-risk construction sites in China, including metro lines in Guangzhou, Chongqing and Beijing, and in mines and steel and petrochemical plants.

The company's founder, Tang Zaixi, told Science that 2,000 helmets are in use and that the company and its clients hold more than 300,000 hours of electroencephalography (EEG) brain data. If a worker's data suggest a high accident risk, the system issues an alert prompting a break. The company says it has issued nearly 5,000 safety reports and prevented multiple major accidents. Those outcome figures are the company's own claims.

Science also reports that Huanao Security and its clients process the raw EEG data, not just the fatigue signal. The practice extends beyond China: in 2021, Wenco International Mining Systems, a Canadian company, acquired SmartCap, a fatigue-detection cap. Science reports SmartCap has been used at mining and construction projects from Ghana and Mexico to Australia.

Our verdict is confirmed. The core claim rests on Science's own reporting and the helmet maker's statements.

Inside the threads

Much of the thread was dark humor, including a mock government alert asking users to log their intimate activity. One commenter predicted the helmets would pair with robot dogs being trialled on construction sites, with legally mandated rest breaks monitored to the millisecond. Another argued employers could use the data to spot who is about to get sick and discriminate against them. In our reading, that sickness prediction goes past what Science reports. A commenter who said they hire contractors joked that many would just show "NO SIGNAL."

Our take

We think the safety framing will make these devices easy to approve and hard to question once they are deployed. A medical ethics professor at Peking University told Science that current low-sensor systems are unlikely to enable genuine mind reading. The same professor said that could change as companies integrate artificial intelligence (AI) to decode brain signals. The mind-reading fears look overblown for today's hardware, in our view. What is underrated is the combination problem. A principal policy adviser at the UK Information Commissioner's Office told Science that collecting other physiological measurements alongside brain data increases the privacy threat. Our take: this is a data inventory gap for CISOs, because this telemetry tends to arrive through safety and operations budgets rather than IT.

What to do

• Ask safety, operations and procurement teams whether any wearable on your sites collects brain, heart, blood oxygen or movement data, and record it under your data classification policy.
• In vendor reviews, establish whether the vendor stores raw signals or only derived fatigue scores, where the data sits, who can access it and how long it is kept.
• Bring legal and HR in before any pilot to settle consent, retention and a written ban on using the data for performance or health decisions, and track it in your governance, risk and compliance program.

What people are saying

A BleepingComputer report says a large-scale watering hole attack associated with Russian hackers has been targeting iOS and Android users visiting compromised sites or fake ones.

What holds up

The account rests on research from security company Sekoia, which attributes the operation with moderate-to-high confidence to APT29, also tracked as Midnight Blizzard. The campaign used high-profile websites in the U.S., Ukraine, the Czech Republic and Bulgaria.

The attackers also compromised a Ukrainian web analytics service, Plerdy, whose tracker was loaded by thousands of websites, mostly in Ukraine, between August 27 and September 3.

On iOS 16.7, the payload went after cookies stored in Safari. On iOS 18.5, it harvested WhatsApp and Telegram databases, Keychain credentials, location data and photos. On Android, the chain targeted Chrome for Android 139 to 145, excluding 143.

Apple and Google have patched all flaws targeted in this campaign, with fixes reaching older iOS releases. Sekoia says none of the payloads established persistence, so a reboot stops the activity until the device visits a compromised site again.

We rate it partly confirmed: the campaign and its patched status are well described, while the APT29 attribution remains a confidence assessment.

Inside the threads

One Reddit commenter said there had been a big uptick in watering hole attacks and suggested a daily reboot, especially on iOS. Another blamed spyware proliferation and artificial intelligence (AI) reverse engineering tools, saying timely patching now means "mere hours in some cases." A reply to a question about delivery said zero-click attacks can also arrive through messaging apps, media attachments and incoming calls, but that those methods were not part of this report. A Bluesky post argued that zero-click describes the interaction an attack requires, not proof that attackers have used it. In our reading, the uptick and AI claims are commenter impressions, not findings from this campaign.

Our take

We think this is a story about patch lag, not new attacker capability. In our reading, the zero-click label fits the exploit chain more than the victim's experience: someone still has to browse to a poisoned or lookalike page. The underrated detail is the analytics script compromise, because it means staff can be exposed on ordinary regional sites nobody would flag as risky. We think the reboot advice is overrated as a defense: a restart ends the session, but stolen cookies, chat databases and credentials stay stolen. For leaders who track nation-state activity through a threat intelligence program, the takeaway is that mobile browsers on old versions are a live target for state groups. Our take is that mobile update compliance belongs in the same reporting as server patching.

What to do

• Use mobile device management (MDM) to set minimum iOS and Chrome versions and block corporate access from devices below them.
• Pull a fleet report for devices on the iOS and Chrome for Android versions named in the report, and prioritize staff with ties to the affected regions.
• For any user who ran an exposed version, revoke active sessions and rotate saved credentials, since a reboot does not undo theft.
• Turn on the hardened protection modes Apple and Google offer for executives and frequent travelers.

What people are saying

The Technical University of Munich (TUM) published an IT security incident notice warning that the incident may affect the personal data of employees and students. The notice carries a status time of Friday, November 6, 2026. The university's press release page lists the notice with the note that all information is constantly updated.

What holds up

According to TUM, unknown individuals attacked the myTUM portal and stole the central login passwords of everyone who had registered with myTUM. Those credentials included a system administrator's login for TUMonline, and the attackers used it against the central campus management system. TUM then took the system offline.

The data the attackers may have accessed includes account passwords, names, home addresses and dates of birth. For employees, it also includes work addresses and work phone numbers. For students, it may also include ID numbers, degree programs and the number of semesters completed.

TUM says it analyzed logs of the attackers' activity and currently assumes that no other TUMonline data, such as grades or applications, was compromised. It says the investigation continues. The university reported the incident to the Bavarian State Commissioner for Data Protection and filed a criminal complaint. It says user accounts with multi-factor authentication (MFA) were protected from this attack.

Because the account comes from TUM itself, we rate the core claim confirmed.

Inside the threads

We think the detail practitioners should focus on is the path from a broad user portal to a privileged account on a core system. In our view, the MFA point will be read as the headline lesson. That is fair but incomplete, because separating administrator credentials matters as much. We would treat any count of affected people, or any attribution to a named group, as speculation until TUM publishes it.

Our take

We think this is a familiar failure: one compromised entry point exposed a shared credential, and that credential reached an administrator. Our take is that the personal data itself is moderate, but the combination of names, addresses, birth dates and program details is good material for convincing phishing. In our reading, password reuse is the downstream risk security leaders should weigh, since staff and students often reuse university passwords at work and elsewhere. We think the logging deserves credit: being able to say what was and was not touched is what lets an organization scope a breach quickly. Our view is that any organization with research partnerships or shared identity federation with a university should treat this as a prompt to review that trust. We would not overstate the impact on research data until TUM says more.

What to do

• Check whether administrator accounts for core business systems can log in through general user portals, and separate them where they can.
• Require phishing-resistant MFA on every privileged account and on any portal that handles central credentials.
• If your organization works with TUM, warn affected staff about targeted phishing and require password changes where a university password may have been reused.
• Confirm that your logging on core systems is detailed enough to scope attacker activity after an incident.

What people are saying

A GitGuardian blog post says threat actors are using an agentic artificial intelligence (AI) framework called ARTEX to search public GitHub for exposed secrets and abuse them. The post credits that finding to research Microsoft Threat Intelligence published on November 5. On Reddit's r/netsec, the discussion treated it mostly as a hygiene story.

What holds up

According to GitGuardian, the agents found OAuth application secrets, signed in as service principals, and moved through Azure and Microsoft 365 tenants. In one case cited in the post, an agent went from scanning GitHub to exfiltrating data from Azure Key Vault in five minutes.

The post describes ARTEX as an agentic penetration testing framework. It says the tool was pulled from GitHub on Oct. 8, right after the first report of use by threat actors. It cites Censys data showing roughly 1,400 publicly exposed ARTEX instances as of Nov. 4. It also cites a Check Point report of more than 1,800, and notes the two figures use different measurement methods.

GitGuardian's own data adds context. It says 64% of the valid secrets it found in 2022 are still active.

The post also mentions links to activity involving South Korean financial institutions, ConnectWise customer environments and WorkOS. It adds that not every reported target experienced a confirmed compromise. In our reading, these details reach readers secondhand, through a vendor that sells secret scanning. We rate the core claim unconfirmed until Microsoft's own report can be checked directly.

Inside the threads

The first commenter quoted the line that searching code repositories for credentials is a well-documented technique. That commenter's answer was simply not to leave secrets on the internet. A reply blamed "decades of missing basic cybersec hygiene."

In our reading, that camp has a point. GitGuardian's post itself calls searching public code for credentials the oldest trick in the cloud attack playbook. The more useful debate is speed. The post's own framing is that attackers are no longer working at human speed.

Our take

We think the technique is old and the tempo is new. That second part is what should change your planning. A five-minute path from a leaked secret to a key vault leaves no room for a weekly triage queue.

The instance counts and the list of named targets are the soft part of this story. We would not brief a board on them until the primary reports are public.

The underrated point is the long tail. Many leaked credentials are never rotated, and an automated agent only needs one of them to work. Service principals and OAuth app secrets deserve special attention, because they often carry broad, long-lived permissions and get little sign-in monitoring.

What to do

• Treat any secret found in public code as compromised. Rotate it first, then investigate whether it was used, starting with high-privilege cloud and identity credentials.
• Inventory OAuth application secrets and service principal credentials in Azure and Microsoft 365. Cut their privileges, shorten their lifetimes, and alert on unusual sign-ins.
• Run automated secret scanning across repositories and continuous integration and continuous delivery (CI/CD) pipelines, including developers' public activity outside your organization.
• Measure your rotation time for an exposed credential in minutes, not days, and fund the automation to get it there.