Google Pauses OSS Bug Bounty due to AI Submissions; Apple Full Disk Access Controls Explain Risks; Kiteworks Flaw Patched During Shutdown

We've talked about AI Slop before — if you are submitting bug reports, make sure that you've reviewed the submission, ensuring it's truly accurate and verifiable. If you're accepting submissions, make sure that your policy clearly states that badly written and bogus reports will be discarded, then use logic to filter these out. If possible, summarize the reported issue to mitigate risks of ignoring a legitimate flaw. Human governance of AI created content is critical, both for credibility and to ensure that you first do no harm.

AI can make people more productive, but unfortunately that also includes making people more productive at producing rubbish. Vulnerability disclosure programmes rely on researchers submitting useful, accurate, and actionable information. Flooding maintainers with thousands of AI-generated reports that somebody has not bothered to validate does not improve security, it simply consumes the time of people who could otherwise be fixing genuine vulnerabilities. AI should help researchers do better work, not simply help them generate more of it.

This is one of the less glamorous ways AI is changing vulnerability discovery and disclosure: it can create findings faster than humans can validate them. When the marginal cost of generating a plausible vulnerability report approaches zero, the cost of proving that report is real does not. Google says the rise in AI submissions became significant enough that it paused its Open Source Software Vulnerability Rewards Program. Programs like this are going to need stronger quality gates, reproducibility requirements, and ways to protect scarce reviewer attention. AI can help us find more real vulnerabilities. We cannot let it bury them in noise.

I know Google is big on using AI to do the full "Find, Fix, Patch, etc." cycle, but it seems they are now seeing that not all AI submissions are valid. I am wondering how they will solve this; it would be interesting to see whether they add hooks or something similar to make it "easier" for AI models to find, fix, and triage bugs. I'm not sure whether that would be through a skill or a set of instructions, but I’m curious to see how this shakes out.

Bug bounty programs have earned their keep over the years, but AI is completely scrambling the vulnerability-finding playbook. Google pressing pause on its program is a clear reaction to the downside. Bottom line: thanks to frontier models, anyone with an account now fancies themselves a security researcher ready to cash in.

Hard not to snicker when AI “slop” impacts the major AI players, but the companies that offer managed bug bounty services have run into the same issue — vetting of participants and adherence to stricter rules of engagement is going to be needed.

Last issue, we were talking about accountability for autonomous agents. This story gets closer to the engineering problem. A consent dialog is not a sandbox. Full Disk Access is intentionally broad, while an agent may take many actions after the user clicks Allow, some of which the user would never anticipate. Apple is right to make the risk more explicit, but the longer-term answer is more fine-grained capabilities, shorter-lived grants, and strong audit trails around what an agent actually accessed. Human consent matters. So does limiting what software can do after consent.

As we give AI agents greater access to our devices and data, we need to remember one of the oldest principles in cybersecurity, the principle of least privilege. An AI agent should only have access to the information and systems it actually needs to perform the task we have given it. We also need to ensure users properly understand what permissions they are granting. Clicking "Allow" should represent informed consent rather than simply being the quickest way to make the annoying pop-up disappear.

This is more of a clarification to make it easier to see what access you're granting. Not a whole lot of things need full disk access, but instead only the files they need, if any. Right now, go into your settings and see what applications have full disk access. That should probably only be your EDR, backup and network file sync apps (OneDrive, iCloud Drive, etc.). Most other things only need specific folders. You can usually have more than one folder, so you don't have to give broad access that includes stuff that should not be accessible.

This is a great move by Apple to make it more deterministic to understand what portions of the filesystem are being accessed by an application. I think Apple needs to do more work compartmentalizing the system and maybe help developers use containers better to put a handle on systems like OpenClaw. Windows is already starting to do this with WSLC, and you have to imagine that now that Apple supports native containers, it will also be advancing that feature.

AI is forcing organizations to rigorously overhaul their Identity and Access Management (IAM) frameworks. This move by Apple represents an explicit acknowledgment of risk and a proactive step to limit liability against unpredictable agent behaviors. Anyone deploying agentic AI must carefully evaluate both the direct and indirect access permissions granted to these applications.

Make sure you're on Kiteworks 9.4.1 or higher. Their Email Protection Gateway (EPG) is a component in the Kiteworks Private Content Network (CPN). There were 11 critical authentication bypass, admin account takeover, XSS, improper access control and authentication flaws in the Kiteworks Core and EPG components. The most critical is tracked as CVE-2026-54154, but there are other flaws which are addressed which don't yet have CVE identifiers. Don't wait for that — apply the update and verify you're following security best practices and leveraging layered defenses. Attackers are searching for unpatched instances, so don't be their success story.

Last week I wrote that this is what threat intelligence is supposed to do: change defensive behavior before an attack happens. This follow-up is about as good an outcome as you could hope for. Kiteworks acted on a credible warning, took systems offline, found a previously unknown critical vulnerability during the shutdown, fixed it, added another protective layer, and the anticipated threat window passed without incident. A quiet outcome can be easy to second-guess because the bad thing never happened. But sometimes that is exactly what successful prevention looks like. Let's not fall into the "boy who cried wolf" syndrome on this kind of thing going forward. Kudos to Kiteworks and to the federal partners who got the warning to them.

Whether this was a narrow escape or manufactured fearmongering from a malicious actor, the CEO made the right call by prioritizing user data protection above all else. At this stage, formalizing the vulnerability as a CVE is likely redundant now that the fix is already available.

I applaud Kiteworks for making what cannot have been an easy decision. Taking customer systems offline based on credible threat intelligence, before having absolute certainty that an attack will happen, requires strong leadership and a clear understanding of risk. It is much easier to explain why you temporarily disrupted a service to protect customer data than to explain after a breach why you had credible intelligence of an imminent attack and decided to do nothing.

At this point, if you're a NetScaler shop and you wish to stay with NetScaler, it'd be a good idea to see if their cloud managed service would be a less risky option for you. While you launch folks at running that to ground, have another team make sure that you're on the latest ADC/Gateway release, regardless of whether you're in a vulnerable configuration. Prioritize updating deployments using SAML authentication for Gateway or AAA virtual servers, and don't stop until everything is updated. The watchTowr FAQ includes information you can leverage when explaining to others and also includes steps to take. Don't overlook running down IoCs; remember you want at check at least 30 days of logs.

At this point, if you are running NetScaler at the perimeter, you must be wondering when this will end. If I were at Citrix, I would have been putting a lot of testing and vulnerability analysis cycles through the NetScaler product. It definitely appears that adversaries are either doing that or have been sitting on critical zero-days for a long time, and we are just seeing a flood of them now, week after week. I’m not sure if this is causing companies to re-evaluate their NetScaler offering, but it just feels like putting this box on the edge of your network is currently a red flag.

The risk here is application and configuration dependent. However, NetScaler includes security functionality and is often relied upon in systems of layered defense (defense in depth). If you use it at all, consider the recommendations with the same urgency as KEVs.

You know those locally hosted Exchange servers I keep bugging you about? Yeah, get them patched right away. If you're running Exchange Server 2016 or 2019, updates are only available if you're under the Period 2 Extended Security Update (ESU) program. Beyond verifying the ongoing need for hosting this service, make sure that there is a trackable plan to update these to Exchange SE RTM with the latest Security Updates, in this case the 9/2026 V2 update.

If Microsoft consider this urgent enough to release "unexpected" updates, then we should act accordingly.

This has taken time, as the direction also included cutting overlap with existing regulations. The proposed version of the rule dates from 2024, and initially was hoped to be complete in October of 2025, but due diligence and funding gaps pushed it out to last week, and with luck it'll be finalized by the end of 2026. If you're an affected agency, make sure you have the capability to report in the required interval, to include identifying who is accountable and what is actually involved in making those reports. You really don't want to tell the regulator/auditor you didn't know; those are not fun conversations.

Organisations operating critical infrastructure are increasingly facing mandatory incident reporting requirements on both sides of the Atlantic. Whether it is CIRCIA in the US or NIS2 in the EU, organisations need processes that enable them to quickly determine whether an incident meets the relevant reporting threshold, identify who must be notified, and gather the information needed to make that report. Trying to work those things out for the first time while responding to a major cyberattack is not a good incident response strategy.

Yet another breach highlighting that vendor risk management remains a discipline cyber security teams need to get on top of. Remember: Once you outsource access to another company, you are relying on that company's security team to protect you. What steps have you taken to ensure you can have confidence in that company's security team? The EU Agency for Cyber Security has published a very good guide on how to manage supply chain risk. https://www.enisa.europa.eu/publications/good-practices-for-supply-chain-cybersecurity

Considering that the population of Denmark is just over six million, this is a pretty comprehensive breach. Called a population scale breach, these were previously seen in Argentina (2021), Turkey (2016), India (2018), and Israel (2026). Danish 10-digit CPR numbers, used for banking, healthcare, and government services, begin with a person's date of birth and are intended to last a lifetime. In that context, this is as significant as grabbing an entire country's database of SSNs. The breach leveraged a third party’s access to the database and involved brute-forcing to enumerate CPR numbers. We all have interfaces for accessing our data rather than providing the entire data set to a partner or customer. The question is: Did we implement monitoring and use detection to catch and stop anomalous behavior? We still need to watch for low and slow, and a lot of new tools are loud and fast for now. Model and verify normal behavior, then catch the exceptions. Rate and data size limits should be in the conversation.

A textbook exploitation of a trusted relationship. This incident serves as a vital reminder that granting third-party access carries two critical responsibilities: thoroughly evaluating the vendor's security posture and actively integrating them into your own risk management framework. Regrettably, it is a lesson we seem destined to keep learning.

Not a lot of details, but it sounds like a supply chain trusted partner was breached or had an employee go bad. No info on how this was detected, which would lead to "why wasn’t it detected more quickly?"

Denmark has many names that are very common; the applications and environment in which the CPR number is used makes the association between the number, which includes the six digit DoB, and the name, much more than simply a tie-breaker. Disclosure of this database will result in an increase in fraud.

Before you breathe easy that Warlock is targeting SharePoint sites someplace else, make sure that you've applied the updates from Microsoft as well as the hardening guidance from CISA. The city of Vicksburg is doing a great job of letting the news media know what's going on, however, looking at their website, it appears to be business as usual — no mention of the incident and impacts on services. Make sure that you're putting notices on your regular websites; don't assume all your users will catch the news. If you're interacting with the city, be kind, as they are probably overwhelmed from all sides and need all the support they can get.

While there is not much one can do to protect oneself after others compromise one’s personal information, Vicksburg citizens should join those of us who act as though our PII is public. We lock our credit bureau data and verify activity on a timely (daily?) basis. We prefer to do business with those who offer strong authentication and out of band confirmation of all activity.