Threat actors have been observed exploiting a critical pre-authentication command injection vulnerability in Citrix NetScaler ADC and NetScaler Gateway to drop web shells and attempt theft of configuration data. LevelBlue's Threat Hunt Operations & Research (THOR) team, which analyzed the exploitation activity across multiple customer environments, said it identified malicious NetScaler
Cybersecurity News and Vulnerability Aggregator
Cybersecurity news aggregator
treemd <(curl -sL https://allsec.sh/md) (as Markdown) Top Cybersecurity Stories Today
Threat actors have weaponized a now-patched security flaw in Zimbra Collaboration Suite (ZCS) to deploy web shells and access mailbox data, according to findings from the Microsoft Security Research team. The attack exploits CVE-2026-73570 (CVSS score: 8.9), an unauthenticated operating system command injection flaw that can lead to remote code execution when Simple Network Management Protocol
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Wednesday added a critical authentication bypass flaw impacting Cisco Catalyst SD-WAN Manager to its Known Exploited Vulnerabilities (KEV), following reports of active exploitation. The vulnerability, tracked as CVE-2026-76504 (CVSS score: 9.8), could allow an unauthenticated, remote attacker to access an affected system with
ANY.RUN researchers traced a US-focused CSuite phishing campaign across 351 sandbox analyses, with 51% of submissions coming from the United States. Technology, manufacturing, government, and consulting organizations showed the highest exposure. By combining Microsoft 365 session theft with remote-access tool deployment, CSuite can turn a phishing incident into broader account compromise, fraud
Why Pentest Proposals Never Seem to Match A compliance officer receives a request for a penetration test, contacts several providers, and receives proposals that appear to describe completely different services. One covers external IP addresses, another includes applications and APIs, and a third promises audit-ready evidence without explaining what was tested. This guide to penetration […] The post Penetration Testing for Compliance Officers: A Non-Technical Buyer’s Guide appeared first on Synack .
Latest
*Hi folks, this is part one of an essay for CEOs, CTOs, and CISOs on how to make sure security work actually gets done. I'll post the second half in a week or so. I run a consultancy that provides fractional CISO services, so helping folks do this kind of thing is my day to day work.* # Part One: Decision-Marking and Process Once you’ve decided that it’s time to start a security program and you’ve figured out what work you’d like to start with — either from your own expertise or an outside review — it’s time to figure out how to get the work done. For some companies, this is easy. If the technical founder or CTO is security aware, comfortable balancing security risk versus product and market needs, and the team is small enough that they can manage everyone’s work streams, that’s pretty much that. We’ve done security reviews for a few clients in this sort of situation, and they’ve gotten great outcomes. Most companies, though, run into some complications when they try to put a security program into practice. In this essay and its sequel (coming soon), we’ll look at the key features an organization needs to successfully roll out and execute a security program. In this piece, we’ll focus on executive decision-making and the project management process. In the second part, we’ll look at what’s needed in the company’s technical ecosystem and engineering team structure, the different categories of security-related work, and how they’re best staffed and organized. Throughout this, we’ll talk about the CISO as the security decision-maker; think of this as a placeholder for whoever is doing that work, as long as it’s someone who isn’t the CEO or CTO. In part two we’ll also talk about the different shapes that role can take and what makes sense when. You can also read this blog [here](https://www.structures.systems/blog), and subscribe via [RSS](https://www.structures.systems/blog?format=rss). # EXECUTIVE DECISION-MAKING The way the executive team makes decisions is the single largest make or break issue for security program success. If it’s aligned with the fundamentals of how security works for organizations, things are easy, but if it’s not, nothing else that happens in the rest of the organization will save the security program. It may still look good on paper, but if, or when, it’s put to the test for real, the technical outcomes will not be good. And it’s not just security that can be impacted here — you may see an impact across the entire business from a security program that’s badly run at the executive level. We can break what’s needed down into five key components: # Trust The first and most important requirement is trust, both toward the other members of the team, including the CISO, and self-confidence on the part of the executive team. Few CEOs and COOs arrive at the point of starting a security program already understanding the ins and outs of security, even if they have some technical background; even many CTOs don’t. This means they’re going to be spending a lot of time making consequential decisions about subject matter that’s a little foreign to them. Good explanations always help, but trust is the core of it. One of the most important skills for an executive is being comfortable with not knowing things — and with other people knowing that they don’t know something. This takes confidence, but it’s the starting point of all decision-making processes. If you aren’t comfortable with what you don’t know, then working with experts to fix that gap is going to be hard. During the process of starting a security program, you’ll learn a lot, but you’re still going to be both leaning on explanations from other people and making decisions with partial knowledge. If you trust those people and you’re comfortable in this process, things can go smoothly. On the other hand, if you don’t trust the people giving you technical and security advice, the process is all-but-guaranteed to fail. Find a team that you trust.\[1\] One of the best ways to build trust is to treat the CISO as a full member of the executive team. Many companies have the CISO report up through the CTO, and we see this as a mistake, as it keeps the CISO from understanding the full context of the business and from having a deep relationship with the rest of the executive team. As the company grows, this becomes less important, but in small companies, the CTO is often product-focused. To be clear, this is good! It’s critical for a company that’s finding product-market fit. As companies get larger, the role of the CTO moves toward shepherding the entire engineering organization, and it’s easier to take on a broader perspective. In our experience, most firms under 200 technical staff are better having the CISO as a peer to the CTO. # Market and Threat Awareness So, how much security is enough? Every CEO or CTO has some version of this question, and the answer is never as clear as anyone would like. A lot of things feed into this — what level of security do potential customers in your industry demand? How regulated is your industry, and what do the regulators demand? How targeted is the company’s line of business — are you just dealing with “being a company on the internet” risks, or does your sector have specific risks? What is your tech stack like — have you made it easy on yourself, or are you in a position where getting to an appropriate level of security is going to take much more work? Finally, who’s after you? You may be just running a chain of fast food restaurants, but if you’re doing it in Kyiv today, you have a different risk profile than you do if you’re in London. As a CEO or CTO, you should have some understanding of what your customers and regulators want, at least, but the rest of this may be new to you. Getting to a shared high-level understanding on market demands and security threats that everyone on the executive team is confident in is critical, as is understanding that new information can change the rest of your security program and impact products too. We’ve had multiple clients who started out selling to mid-sized companies and had a real shock with their first few big enterprise clients. If a shock like that happens to you, take advantage of it — the world has just delivered you some expensive information and the sooner you learn from it the better. It’s not unreasonable for the executive team to want some additional information from sources other than their CISO — talking to their peers at other companies in the same industry, for instance, can make sense. At the end of the day, though, every company is different. There may be factors that put your firm in a different place than peers that seem similar to you. There’s a fine line between information gathering and second guessing or trying to negotiate with reality, and this is where trust is critical. How deep of an understanding of market demands, threats, and security strategy each member of the executive team will need depends on their exact portfolio. In general, the CTO, CEO, COO, and General Counsel are most involved, but other folks should still have a general understanding. Depending on the roles you have, more people may be on that list. If you have a Chief Product Officer, for instance, they may need a deeper understanding than the CEO, even. Talking through the structure of how work is split up should be an early part of framing the CISO role and their interactions with the rest of the executive team. # Strategy, Risk, and Trade-Offs Once you understand what security looks like for your firm, the next step is figuring out a technical strategy for security and how that interacts with the technical and business strategy of the company as a whole. This is where trade-offs need to be made, and the core of those trade-offs is the risk tolerance of the company. If you’re in a heavily regulated or security conscious line of business, have solid product-market fit, and are on your way to delivering well without massive growth pressure, you may have a low tolerance for security risk. Things are going your way and the only thing taking security risks is going to do is mess everything up. On the other hand, if you have a high risk tolerance in other areas of the business, it may be the case that your security risk tolerance should match. Security risk is complex, however, despite what many risk register vendors would like to tell you. You’re not just taking a risk for the company as an entity, you’re also taking risks for your staff and your customers, personally. Even the least risk-averse firm has some basic ethical (not to mention legal) obligations here. Some companies also make trade-offs that come from the founders. We’ve had clients with high bars for staff privacy, even with respect to automated tooling, who were willing to accept risks to the entire firm to maintain that privacy. Similarly, we’ve had clients who valued independence from third-party vendors more strongly than SaaS-heavy industry norms, leading to technical trade-offs on security risk (not to mention product velocity). It’s your firm, and you get to make those calls. The critical issue is that everyone making relevant decisions understands the company’s risk tolerance and has a good rubric for the way the executive team expects decisions to be made. If the folks doing the work don’t have a solid idea of what solutions will be acceptable, conflict is inevitable. Most of the time, doing something for security means you can’t do something else with the same time or money. Ideally, you don’t just have a long list of waiting security tickets, but a technical strategy for the way security outcomes will be achieved for the company that acts as a through-line across all the security work. Explaining this strategy is on the CISO and CTO, and it’s worth talking through it until e.g. the CEO can recognize it when making relevant decisions. For folks without a technical background the through-line of a security strategy can be hard to see, as in practice security can be kind of like trying to put your finger on all the holes in a colander. That said, trying to negotiate with technical reality does not work. There is a bar for security that comes just with being a company that exists on the internet, and that bar doesn’t change even you stare at it really hard. If the CISO comes to the CEO and says they need two engineers for a quarter each for patching known vulnerabilities and system hardening, saying they can only have one doesn’t make the risks to the business from the other project go away. If as a CEO you’ve expressed a risk tolerance for the company as a whole and the CISO is giving you a plan that achieves that risk tolerance, they’ve made the professional judgement call you’re asking them to make. If there’s context that makes it impossible, they should have it — and then work with you to get to a plan that is possible. The right time to handle this is up front, making sure that as the CISO is starting to develop the company’s security strategy, they have a clear understanding of what resources are available, what the constraints and go-to-market or product strategy is, and even what investor relationships are like. It’s possible to hold all this information close to your chest, but then you can’t complain when you get a strategy based on what the CISO does know. Reaching out to your board to help understand these risk trade-offs can be useful, and including the CISO in that conversation is helpful. Remember also that as a CEO, you get to frame this conversation — if you choose an us versus them framing between security and product, you will get the result you asked for. In reality, these trade-offs often aren’t zero sum. A good CISO and CTO should look at how the security strategy interacts with the technical and business strategies of the company. In some cases, the work needed for security can open up possibilities for the whole company’s technical strategy, and in the best case even create business opportunities that weren’t possible before. This kind of strategic synergy\[2\] requires that the CEO, CTO, and CISO all understand the high-level technical and business strategy, including the pressures, market demands, and structural options that the business may be exploring or facing. The business side of this is sometimes seen as a long way away from the CISO’s domain, especially in less technology-centric companies. While the CISO doesn’t need to hear every detail of the sales team’s current challenges, they should have access to as much of that information as is practical. A good CISO is a deep partner of the CTO and their work will impact the business as a whole. As before, trust is key. # Commitment and Decisiveness Some executive teams are good at making decisions and sticking to them, even to a fault. Some aren’t. A security program at a company that hasn’t had one before is almost without exception the largest set of work the company has undertaken that’s not driven by product-market fit, if we exclude non-security regulatory demands in highly-regulated industries. It will impact the rest of your roadmap, and it will impact your ability to implement last-minute product changes. This can be terrifying, and for some executives, it means making a kind of decision they haven’t faced before. Making the wrong decision and sticking with it until you get information that demonstrates that you were wrong is often less bad than being indecisive. Now, if the wrong decision was made, the company still has to weather the event that reveals this — in some cases, hindsight might show a much brighter alternative world. When it happens, though, the only thing to do is re-plan and move forward. Failing to make a decision, or worse, getting into a loop of starting, getting cold feet, doing something else, and then getting corrected back to the original plan can be far worse than just sticking to the wrong decision. The cost of security work is hard to estimate ahead of time (more on this below), but stopping and starting or reprioritizing is a sure-fire way to make it more expensive. # Cultural Leadership As goes the executive team, so goes the company. If the executive team expects everyone else to comply with a security policy but lets themselves be the exception, everyone else will try to get out of it — don’t be that guy. Starting a security program is often one of the first changes from being a startup to being a big-boy company, and one of the failure modes is when security end up being the fun police who no one wants to work with. While there are some things that a security team can do to mitigate this, the executives are the ones who set the tone here. If they make clear how things are going to change — and here’s a place where it’s useful that the whole executive team understands how security work will impact people’s work, especially on the IT side — and why it matters for the company, showing that the security team has their trust and approval, outcomes are better for the whole firm. This is why making it clear that they’re following the same rules as everyone else is so critical. It’s a big transition for the whole company, and it’s a lot easier if everyone is on the same side going through it. IT and security can handle all the day to day communications, but they need the CEO to make it clear that the changes are coming from the top. As an aside, there are two choices you can make early on as a founder that will make your life easier when it’s time to start taking security seriously, especially if you know the company will have a low risk-tolerance. First, set norms that company devices and accounts are for work, and that while folks can do some personal stuff on them, they shouldn’t think about these as personal devices. Partially, this is just a good idea overall — anyone who has ever dealt with the discovery process around a lawsuit against their employer is happy to keep everything in their personal life as far away from work devices as possible. Primarily, it means it’s less of a shock to the company culture when devices start getting hardened or monitored more closely. The other choice is to be very, very, very careful about never using the access you have to company systems to check up on employees except in cases where you’re trying to rule out malicious action\[3\] — and even then, it’s best to be up front about it to the rest of the team, even if it’s after the fact. Building a security program unavoidably means that the security team will have access to tools and data that could violate the privacy of employees. If staff can’t trust that that access will be used with the utmost care and won’t be used for any purpose other than technical security outcomes, there will be much more conflict around a security program rollout. If you’re worried about one of your employees slacking off or working their side-hustle on company time, do not use Workspace SuperAdmin access to catch them. Go have the uncomfortable conversation instead. # PROCESS Once the executive team is onboard with the work, knows how to talk to each other and make hard decisions, understands the risks and threats, and is showing the company that they care about security, it’s time to get the rest of the company moving. In small companies, the CTO says go and both developers get to work and the whole problem fits in everyone’s head — but teams this small are going to be hard-pressed to start anything that one would call a security program. The team size where starting a security program makes sense is around the 10-20 engineer mark (more on this in part two), meaning there are at least two different streams of work happening, and maybe more like a dozen. Security is often the first stakeholder needing to get engineering work done that’s not driven by the product roadmap or vision. Individual engineers or teams may have had internal work that they’ve done alongside their product-driven work — tooling they needed, quality of life improvements, bug fixes, etc. — but this is driven bottom up; they’re the customer for their work. Now that there’s a second top-down stakeholder, the way decisions are made needs to change. # Clear Planning Decisions The process by which the team makes decisions about what work gets done does not matter as long as a) it’s not too onerous on the team and b) both the CISO and CTO understand what the decisions are, have a say in the decisions line with the priorities set by the executive team, know how the resulting work is going as it happens, and are both involved when the work gets off track or priorities need to be changed. Above all else, how and when decisions are made and what decisions have been made needs to be clear to everyone involved. This is more difficult than it sounds. The first requirement in planning work is that there be a plan. It’s not uncommon to see early teams where there is no plan beyond what folks will start working on next Monday. Sometimes this is because design and development is happening just-in-time, in response to customer requests day by day. Sometimes there’s a grand plan in someone’s head and there hasn’t been a need to write it all out. Starting a security program is often a driver in moving from a sprint planning plus vague notes in a ticket backlog to at least limited quarter-scale planning. Once a plan exists somewhere, there’s a place for the CISO and CTO to write down the decisions they make and a way for the rest of the team to understand those choices and the priority they have. Security work is often the definition of important but not urgent (until it would have needed to have been done last week), and without a plan, urgent product work can keep cutting in line. Once there’s some kind of plan (and this can be a whiteboard or a text file in source control), there needs to be a way that everyone agrees on for how decisions get made. It’s also necessary that decisions are made\[4\]. If the CTO, their two managers, and the two most senior engineers get together every Monday and make those decisions, it’s easy — make sure the CISO is there too, call the group back together if the plan changes on Wednesday, and you’re solid. In some cases, especially in fast moving teams weighted toward senior- or staff-level engineers, the CTO may be steering by expressing some general intentions and then expecting their team to go make the actual decisions and do sensible things. This is great, until someone else comes along and also expresses some general — or worse, specific — intentions. If the team is used to executing without checking back in — say there are 25 engineers and the first manager starts next month and the CTO is out of bandwidth\[5\] — this can result in surprises. Even if the end result is good, the surprise itself causes problems. An organization like this isn’t going to spin on a dime to epics and Gantt charts, but they don’t need to. The CTO, with input from the CISO about their needs, needs to make it clear to the team what kinds of things they have the authority to make calls on, what they want to be notified about, and what decisions they need to be involved in. They also need to provide a channel where the team can get decisions back in a timely manner, and make sure the CISO has visibility too.\[6\] Whatever structure is used, it needs to apply to everyone. If the CEO gets a critical request from the biggest client, it needs to go through the same process — even, and maybe especially — if there’s no way that won’t be the top priority. Even if all the other plans get swept off the table (it happens, and it’s often the right call), everyone knows what happened and why. If there’s a process, it needs to be the process. If the process is too heavyweight to follow in a case like this, it’s the wrong process for the company at this stage. See if there’s a lighter, faster version that still does what’s needed. In larger development teams, we’ve seen issues where there’s a plan on paper, but it doesn’t relate much to what happens. For instance, if a team has a big product project and a big security project and both of them are supposed to get done this quarter, but the product project has their quarterly bonus riding on it, the security work isn’t getting done. You get the work you incentivize, and if you’re going to try to use incentives to drive team performance, they should map to the priorities you agree on. This problem gets worse when it’s not clear to all stakeholders what work is even happening. If you end up with a decision process that only has one cycle per quarter at the CTO/CISO level for prioritizing work and work isn’t done to plan… well, good luck. # Estimation If you’ve got two pieces of work that are at an equal priority, it would be useful to know how long they’ll take when you’re deciding what to work on. Unfortunately, guessing ahead of time how long it will take to get a nontrivial piece of software into a specific state is a fool’s errand.\[7\] Instead of deciding ahead of time that an unknowable amount of work will take 29 and ¼ days, ask the team that owns the system in question what kind of a job they could do on a given feature in a given amount of time, and what the contingencies look like. Work will expand to fill the time available, but it will sometimes also contract. For instance, you might be able to replace the vulnerable pattern that you’ve been using for some set of operations with a safer library so new development can go forward in a better state and then pick five random legacy instances to fix in the time you have, but you can’t also fix all of the other places the old pattern is used. Fine! Now you have a better instinct for what doing the rest of it will look like, you’re no longer adding to the technical debt pile, and the next time this work comes back up the priority stack, you can get further. Now, as a security person, this pains me — an incomplete migration does mean more tech debt because there are two ways of doing things, and parts of the system are still vulnerable. However, this is better for me than either never getting that work scheduled because I can’t get exclusive use of that team for an entire quarter at once, or starting the work with an estimated two weeks scheduled and then hard blocking two other teams when they run a month over — meaning I’m definitely not getting their time back to finish the job later. Early in the team’s security journey, time-boxing work so you can get some improvement in a bunch of different places while doing other work is often more useful than trying to get things perfect in one place. There will always be more security work that could be done than can be done, even if you do nothing else. That said, sometimes you will have specific fixed security requirements, the same as any other product requirement. Most often this is either a direct compliance requirement, or a compliance requirement that your customers face. Here, it’s important that you treat these as what they are — requirements for your product to find market fit. Yes, your security team is going to be taking the lead on converting what you’re hearing from your customers into specifications, but it’s important to distinguish between work the security team selects to reduce the risk to the company and work the company does so they can sell to customers (even if it will also reduce risk to the company). # Interleaving Work There is a cost to make a change to a given part of a system — any change at all. An engineer may need to remember how that service gets deployed, relearn the structure of the code, or go familiarize themselves with a piece of the tech stack they haven’t touched before. If you’re going to pay that price for one thing, you might as well get two things done at the same time. If a system is getting replaced, adding some additional architectural changes beyond the one that drove the upgrade is often cheaper. While you’re in there reworking how we do all the billing tracking, how about we also stop passing all the account data around in big JSON blobs so we don’t need to parse risky customer-supplied data everywhere. This kind of interleaving of work is a big part of making security changes cheaper when you have legacy systems, and finding opportunities for it is key to a cost effective security program. This is why the CISO doesn’t just need to know the plan for security work and how it’s going, but also everything else happening in engineering. The whole team (in small organizations) should know the plan too, so they can help spot these chances. # END, PART ONE In this part, we’ve gone over what you can do to make sure your new security program will be successful within the executive team and in terms of how you plan and decide on work. In the next part, we’ll talk about the kind of resource limits you may run into when building out a security program, the nature of the five different kinds of security-related work, and how best to take care of each one. *Systems Structure Limited is a boutique security consultancy, providing fractional CISO services to startups. Over the past nine years, we’ve built security programs for fifteen different companies, and our work has been responsible for hundreds of millions of dollars in capital raised by our clients. If you’re reading this essay because you’re getting ready to start a security program at your startup, let’s talk!* # Footnotes 1. Getting comfortable with not knowing things and self-confidence in general is outside of the scope of this essay, but therapy is a great start. Just saying. 2. Ugh, I can’t believe I just typed that, but that is literally what we’re talking about here. 3. If you’re tempted to do this, talk to your lawyer first and tell them I sent you. They’ll thank me. 4. You would think this was obvious, wouldn’t you? But a lot of teams have issues here. 5. I have never met a CTO who didn’t have too much on their plate. 6. Even if the CTO does have bandwidth and there is a planning process, talking through with the team where the limits and expectations of agency are for them will pay dividends, especially in emergencies. 7. Many people will tell you differently, especially before it turns out they were wrong. These people are rarely the ones doing the work
Every security leader at a bank, insurer, or asset manager has had a version of this conversation: Security wants to eliminate a class of vulnerabilities. Engineering explains what it would take to upgrade the platform where they live. Somebody prices out the regression testing. Somebody else raises the change-freeze calendar. The finding gets an exception, a compensating control, and a date
OpenAI on Wednesday said it identified and disrupted a coordinated distillation campaign that was designed to illicitly extract protected reasoning from its artificial intelligence (AI) models. A "core cluster of the activity," going back to the first week of July, has been attributed to individuals associated with Moonshot AI, a Chinese AI company based in Beijing. It did not cite any
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Wednesday added a critical authentication bypass flaw impacting Cisco Catalyst SD-WAN Manager to its Known Exploited Vulnerabilities (KEV), following reports of active exploitation. The vulnerability, tracked as CVE-2026-76504 (CVSS score: 9.8), could allow an unauthenticated, remote attacker to access an affected system with
In an exclusive interview with WIRED, Paragon Solutions CEO Andrew Boyd reveals the limits of the company’s promise to keep bad actors from abusing its powerful espionage tool.
I emailed Agoda's security contact on June 18 and heard nothing for 28 days. Now their security.txt points to HackerOne, and my report there was closed as a duplicate
I do bug bounty hunting and I want to share how a simple responsible disclosure turned into a mess. Two different channels failed me here, and I think both are worth talking about. In June I found a vulnerability on Agoda's main domain. Agoda has a public HackerOne program, but only one specific path is listed as in scope, and what I found was on a different part of the same domain. I wasn't sure if I was allowed to submit it there. I didn't want to break any rules, so I opened a ticket with HackerOne Support and asked two simple questions. Can I submit a bug on the same domain if the path isn't listed in scope? And if not, should I report it directly to Agoda's security contact instead? The reply didn't really answer either one. It told me to avoid reaching out to the program directly and to not work on out of scope assets, because reports marked as spam or not applicable can hurt my signal and reputation. That was it. No "yes, submit it", no "no, email them", nothing about what to do with a real bug that sits on the same domain but outside the listed path. The ticket was then closed. So the platform's guidance boiled down to "don't touch it" with no word on where it should go. The only other place to look was Agoda's own security.txt. When I checked in June, the Contact line was an email address, [vulnerabilities@agoda.com](mailto:vulnerabilities@agoda.com), with no mention of HackerOne. I didn't take a screenshot at the time, which was my mistake, so the best I can offer is this archived copy from February 2026 showing the same setup: [https://web.archive.org/web/20260206144235/agoda.com/security.txt](https://web.archive.org/web/20260206144235/agoda.com/security.txt) On June 18 I sent a full, detailed report to that address. Clear steps, clear impact, everything a security team would need. Nothing came back. No auto reply, no acknowledgement, nothing. On June 21 I tagged Agoda on X and asked them to check their inbox. Their public reply was a generic line about following the account so they could DM me my "booking details", which had nothing to do with a security report. I DMed them anyway, and the rep told me to be patient while the relevant team reviews it and that response times vary. Fair enough, so I waited. I waited 28 days. Still no acknowledgement from the security email, and the issue was still live. So on July 16 I submitted it through HackerOne, since it was the only way I could think of to get it in front of someone who would actually read it. It was closed as a duplicate within a few hours. The original report was filed on June 29, which is 11 days after I emailed their official security contact. HackerOne's triage also told me the program has already acknowledged the issue and is working on it through that original report. Here's the part that bothers me most. If you open Agoda's security.txt today, the Contact line no longer lists that email. It now points to their HackerOne report form, and there's a Policy line pointing to the program page. I don't know exactly when it changed or why. My guess, and it is only a guess, is that it was updated some time after the other researcher's report came in, but I can't prove that. What I do know is that in June the published instruction was to email an address that, as far as I can tell, nobody was answering, and I did exactly what the file told me to do. So either my email was never read, or it was read and nothing happened with it. Either way, a valid issue was sitting on a major travel booking site, and the only reason anyone is working on it is that someone else happened to use a different route. I'm not complaining about the duplicate. Dupes happen and I get it. My problem is the system around it. HackerOne gave me no usable guidance on same domain assets outside the listed scope, and Agoda's published security inbox went nowhere. I tried to follow the rules at every step and ended up with nothing. I'm keeping all technical details out of this post on purpose, because I don't want to put users at risk. I have the original email, the HackerOne support ticket, the X conversation and the duplicate notice saved with timestamps if anyone needs proof.
Google on Wednesday announced its latest frontier artificial intelligence (AI) model, Gemini 4 Argon, that it said is being rolled out to a set of trusted cyber defenders through its Fairwind Program. "It delivers frontier performance in complex workflows across real-world software engineering, enterprise knowledge work like legal and finance, and cybersecurity defense," Koray Kavukcuoglu,
London, UK, 1 October 2026 – Heimdal, a global cybersecurity provider, today announced a partnership with Elovade, a European IT security distributor with 250 experts across five countries, to bring its unified security platform to managed service providers (MSPs) across the DACH region: Germany, Austria, and Switzerland. The move extends a relationship that began a […] The post Heimdal partners with Elovade to bring unified cybersecurity platform to the DACH region appeared first on Heimdal Security Blog .
Security researchers have published the first public proof-of-concept for CVE-2026-86950, an Apple CoreGraphics flaw Apple says may have been used in attacks against specific targeted individuals. The trigger is a malicious PDF with a crafted embedded font that crashes unpatched iPhones and Macs. The code causes a crash, not an execution error. Turning the memory corruption into a working
Cryptocurrency exchange Bitget on Wednesday confirmed that attackers who stole $387.5 million last week exploited a zero-day flaw in third-party security products, citing ongoing investigation findings from SlowMist. "Their investigation identified malicious activity involving third-party security products, including a zero-day vulnerability, and recovered a customized tool used by the attacker
MetaMask on Thursday said it's responding to what it described as an "ongoing security incident" impacting part of its infrastructure. "We are actively addressing and remediating the issue internally, in coordination with external partners and security advisors," the software cryptocurrency wallet maker said. "At this time, we have identified no immediate threat to MetaMask wallets." MetaMask
Threat actors have been observed exploiting a critical pre-authentication command injection vulnerability in Citrix NetScaler ADC and NetScaler Gateway to drop web shells and attempt theft of configuration data. LevelBlue's Threat Hunt Operations & Research (THOR) team, which analyzed the exploitation activity across multiple customer environments, said it identified malicious NetScaler
HANDLE Duplication internals : What happens behind the scenes when you call kernelbase! DuplicateHandle( )
[https://github.com/Splinters-io/blinder](https://github.com/Splinters-io/blinder) \- on a napkin it explores the idea of blinding AI from the real target by doing some reverse proxying, this achieves two goals, first masks the content as best it can so that the functions still remain to be interrogated and second, AI thinks its local as you'l hit it from 127, or .local address, it will remove any extra thinking about deciding to help you or not based on the context that it might normally learn if you just said 'hey claude, let's attack gmail' or whatever - I'm hoping that the idea in principle lands, even if my hatchet-job doesn't - I thought I'd get it out there - I've haven't seen any approaches like this yet - work in progress, steal the idea, make it better, hide from sky net etc ... :) - thanks
Cytactic CEO on a hospital ransomware case where staff couldn't trust patient records, and why most CISOs never rehearse their worst day [Podcast, 33 min]
Disclosure: my studio produced this episode of Responsible Disclosure, Zafran's podcast. Sharing it because a lot of it is about incident response in practice, and I've summarized it below so you can skip to what's relevant. Nimrod Kozlovski has spent about twenty years across cyber law, VC, and crisis management, including running incidents at Fortune 500 companies. A few parts I think this sub would care about: At 03:12 he walks through three incidents: stolen source code at a homeland security company, a crypto wallet takeover, and a hospital extortion where staff didn't know whether patient records had been altered. At 13:03 and 16:21 he argues AI has cut the time from vulnerability to exploitation to minutes, and that attackers are chaining identity, permissions, and applications to get past layered defenses. At 24:03 and 26:01 he gets into why most CISOs face their worst day with little rehearsal, and why tabletops matter when you're deciding on partial information. Also a fun story at 09:21 about the DEF CON crowd deciding he was a fed. For the IR people here: do your tabletops include injects where the data turns out to be wrong? The hospital case made me think most exercises assume you can trust your logs and records. [https://youtu.be/B8YB42zON8U](https://youtu.be/B8YB42zON8U)
Hi guys, I send out a weekly newsletter with the latest cybersecurity vendor reports and research, and thought you might find it useful, so sharing it here. All the reports and research below were published between September 21st - September 27th. You can get the below into your inbox every week if you want: [https://www.cybersecstats.com/cybersecstatsnewsletter/](https://www.cybersecstats.com/cybersecstatsnewsletter/) # Inside the SOC **2026 Creating a Modern and Mature SOC Report (Optiv)** How SOCs staff their teams, which tools they use, and how they measure success as incidents rise. **Key stats:** * SOCs manage an average of 2,566 alerts and incidents a day, with 36% investigated through manual processes. * 46% of IT and security professionals identify insufficient staffing as a critical gap in SOC effectiveness. * 64% say identity visibility is very or extremely important (though only 32% say identity and privileged access events are centrally visible to their SOC). *Read the full report* [*here*](https://www.cybersecstats.com/r/69ffd944?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* **SANS 2026 Threat Hunting Survey (SANS Institute)** A survey of 500 security practitioners and leaders on how they hunt for threats, what gets in their way, and what’s changing. **Key stats:** * 50% name data quality or quantity as their primary barrier to effective threat hunting. * 40% of organizations formally measure hunt outcomes, down from 64% in 2024. * 37% have a formally defined hunting methodology, down from 51% in 2024. *Read the full report* [*here*](https://www.cybersecstats.com/r/58869820?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* **The Detection Blind Spot (Conifers)** Which threats organizations can actually detect and why so many of their detections need fixing. **Key stats:** * Organizations have working detections, hunts, or other visibility for only 63% of the threats they identify as relevant. * Coverage extends to 64% of the MITRE ATT&CK techniques relevant to their environments. * 47% of existing detections need attention before they can be trusted to work as intended. *Read the full report* [*here*](https://www.cybersecstats.com/r/e2f16461?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* # AI Security **Global AI Confessions Report: CIO Edition 2026 (Dataiku)** If you’re a CIO and struggling to prove AI’s value… you’re not the only one. **Key stats:** * 67% estimate that at least 51 AI agents are running in production. * 90% are confident they have complete tracking of running agents, yet 81% lack complete oversight of agents created outside approved systems. * 72% cannot consistently measure whether their agents deliver the intended business outcomes. *Read the full report* [*here*](https://www.cybersecstats.com/r/ff95a3b6?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* **The 2026 State of AI and SaaS Security (LastPass)** How companies are managing the security risks of AI tools and SaaS apps. **Key stats:** * 92% of business admins say AI is already in use across their organization. * Only 27% have an enforced AI governance program. * 42% have no technical controls, such as allow lists, block lists or DLP rules, for employee access to AI tools. *Read the full report* [*here*](https://www.cybersecstats.com/r/0eeb7968?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* **15,465 MCP Servers. 0 Governance. (OX Security)** Some AI agents may still trust MCP hostnames whose domains anyone could register for as little as $4. **Key stats:** * 2.3% of analyzed MCP hostnames no longer resolve. * Six hostnames that had previously resolved were unregistered and available to buy for $4 to $12 a year. * 15.6% of analyzed hostnames resolve outside the US, including 19 in China and 18 in Russia. *Read the full report* [*here*](https://www.cybersecstats.com/r/2960cc0e?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* # Network Security **What 47,700 Segments Reveal About Network Segmentation (Forescout)** How well organizations separate devices on their networks (spoiler: not that well). **Key stats:** * Nearly half of segments containing OT or medical IoT devices also contain IT or other IoT assets. * Of the 478 segments with a point-of-sale system, only 95 (20%) are exclusive to those systems. * Only 51 of the 2,266 segments with IP cameras (2%) contain cameras alone (60% also contain workstations). *Read the full analysis* [*here*](https://www.cybersecstats.com/r/16eb9cf9?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* # Bot Activity **State of Bot & Agent Security Report, 2026 (DataDome)** Interesting insights based on analysis of trillions of requests and tests of more than 20,000 websites. **Key stats:** * Bad bot traffic increased 124% between July 2025 and June 2026. * Scraping made up 70.9% of bad bot traffic and grew 185.2% year over year. * In an expanded test, 65.3% of websites stopped none of the 10 bot types evaluated. *Read the full report* [*here*](https://www.cybersecstats.com/r/bdba6826?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* # SaaS Security **State of M365 (ShareGate)** IT teams feel in control of Microsoft 365. The incidents say otherwise. **Key stats:** * 77% of organizations experienced at least one Microsoft 365 governance incident. * 65% of teams learn about governance problems after the fact, through quarterly audits or user complaints. * 38% leave former employees or guests with access they should have lost, and 26% have had sensitive content reach the wrong people. *Read the full report* [*here*](https://www.cybersecstats.com/r/89f0361d?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* # Brand Protection **The State of Online IP Risk 2026 (CSC)** Criminals are using AI for IP theft. Meanwhile, brands are using AI to fight back. **Key stats:** * 90% of senior executives specializing in IP law say AI-enabled systems are increasing online IP infringements. * They rank impersonation (40%), phishing (39%) and domain name abuse (39%) among their top concerns. * 73% cite slow enforcement processes as a top challenge. *Read the full report* [*here*](https://www.cybersecstats.com/r/2902d373?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* # Social Engineering **AI-Driven Social Engineering Attacks (Gartner)** Some of the calls CISOs are getting now aren't from real people. **Key stats:** * 41% of CISOs report at least one social engineering incident involving a deepfake during an employee audio call in the previous 12 months. * 36% report one involving a deepfake during a video call. * 79% report email phishing, spear phishing, or business email compromise. *Read the findings* [*here*](https://www.cybersecstats.com/r/cda5293e?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* # Enterprise Perspective **The Impact of Agentic AI on Network Operations (Cisco and Omdia)** A report on how widely enterprises are using AI agents in network operations and how much control they’re willing to give them in production. **Key stats:** * 51% of organizations run agentic AI that acts in production today. * 82% are comfortable letting AI make at least some production network changes without prior human approval. * The average organization generates about 4,100 monitoring alerts and events a day, more than half of them network-related, and nearly half of network alerts are closed without investigation. *Read the full report* [*here*](https://www.cybersecstats.com/r/5c765b0d?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* # Industry-Specific **Operational Resilience in the Age of Connectivity (Rockwell Automation)** Industrial organizations report plenty of confidence alongside plenty of incidents. **Key stats:** * 90% are confident they can prevent, contain or recover from one. * 46% experienced a cyber incident in the past year. * 45% plan to apply AI or machine learning to cybersecurity initiatives over the next 12 months. *Read the full report* [*here*](https://www.cybersecstats.com/r/923021e6?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* **The State of Networking, Security & AI in Financial Services (Nile)** For many financial services organizations, network security and audit readiness is still a lot of manual work. **Key stats:** * 57% experience network disruptions at least monthly that affect transactions, trading, digital banking or internal operations. * 79.5% rely on manual intervention for threat detection and containment. * 59.3% report a moderate to significant manual burden to maintain audit readiness. *Read the full report* [*here*](https://www.cybersecstats.com/r/e16f7c2b?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.* **Public Sector AI Readiness Report (SolarWinds)** Governments in the US and UK are using AI a lot, but they don't always know where or how. **Key stats:** * 84% of UK public sector IT professionals monitor AI behavior to some extent. * Only 29% describe that monitoring as comprehensive. * 30% have a formal AI governance framework that is actively enforced. *Read the full report* [*here*](https://www.cybersecstats.com/r/c4e38f74?m=50f43416-1146-4a3d-a1e1-5afc95e09a39)*.*
Hi this is my repo support pls https://github.com/mein-0/gvcidrv64/
Threat actors have weaponized a now-patched security flaw in Zimbra Collaboration Suite (ZCS) to deploy web shells and access mailbox data, according to findings from the Microsoft Security Research team. The attack exploits CVE-2026-73570 (CVSS score: 8.9), an unauthenticated operating system command injection flaw that can lead to remote code execution when Simple Network Management Protocol
Threat actors are abusing ChatGPT Custom GPTs to disguise them as legitimate product offerings and direct unsuspecting victims to malicious sites that employ ClickFix lures to deliver malware. Huntress, which observed the activity in late September 2026, said it marks the abuse of yet another feature in trusted artificial intelligence (AI) platforms. Prior campaigns have weaponized shared
[https://www.teamviewer.com/en/resources/trust-center/security-bulletins/tv-2026-1010/](https://www.teamviewer.com/en/resources/trust-center/security-bulletins/tv-2026-1010/)
This week, Cloudflare's Impact programs will reach $100 million in donated services. It's a significant milestone, and one that we are proud of because it means that thousands of organizations, like journalism outlets, civil society, state and local governments, election management bodies, and public schools are being protected from cyberattacks. But Cloudflare's Impact programs have never been about philanthropy. They are a fundamental part of our business and our mission, and they continue to help guide almost everything we do. As we celebrate this milestone and our 16th Birthday Week, we wanted to revisit not only how we got here, but also how our Impact programs continue to grow and evolve to help those working for the public interest. Free → Impact Cloudflare started as a free service. The original idea was to provide a basic version of our services to developers and small businesses for free, and then use the data about cyberattacks on their websites to build more sophisticated products that we could sell. However, we quickly discovered that some of our free customers were not only doing essential work, like reporting on corruption in Africa or on the Russian invasion of Crimea, but also experiencing some of the largest attacks on our network. That realization changed how we thought about our free services. We committed not only to making them available for free for everyone, but also to doing more for organizations being targeted by powerful adversaries simply for serving the public. Cloudflare launched Project Galileo in 2014 to provide more advanced security services for important but vulnerable people and organizations online, including journalists, human rights defenders, and civil society groups. Today, the program includes more than 3,500 domains in over 120 countries. In 2025, Cloudflare blocked more than 38.5 billion DDoS, website vulnerability, email phishing, and other cyberattacks against Proj
From our conversations with companies at every stage of their AI adoption journey, we've seen some common patterns. First, there is an exploration period as you bring on every new tool, dole out API keys freely, and let the tokens flow. Then, you converge on the canonical tools for your organization for agentic coding, for non-technical workflows, for running and deploying agents. As companies formalize their AI adoption, they want to manage and oversee token spend for users, but budgets and rules only go so far. The best savings are the ones users never notice. Today, we are releasing Cloudflare's Auto Router in public beta, available through AI Gateway. Set your model to cloudflare/auto and the Auto Router will automatically route each request to a model that is capable enough for the task, without requiring an end user to think about model selection. Our early results using the Auto Router internally through our OpenCode harness show a cost savings of up to 30% when compared to using only frontier models like OpenAI Sol and Anthropic Claude Opus. Why we built this From our own experience tracking AI spend at Cloudflare, we’ve learned managing costs requires a multipronged approach. Previously, we talked about how to set budgets and limits around AI spend, and how to see who is spending across your organization by linking employees to their AI usage. In many harnesses, including OpenCode, Claude Code, and Codex, individual users still select models manually. Of course, not all tasks are created equal, and often individuals end up using models that are overkill for their work. For example, you don't need Opus-level intelligence if you're looking to summarize an email or chat thre
As agents help us build more complex applications, both humans and agents need a better way to stay on top of what goes wrong in production. Coding agents can already query observability data, navigate a repository, change code, write tests, and open a pull request. What remains manual is connecting those steps: recognizing that repeated failures come from the same bug, gathering the relevant logs and traces, sending that context to an agent, and checking whether the fix worked. Without that structured handoff, the agent must search raw telemetry to reconstruct the scope and context of the failure before it can investigate. Today, we are introducing Issues , built-in error monitoring for Cloudflare Workers (now in open beta!) to streamline this workflow. Issues can: Group repeated exceptions, 5xx responses, and error logs into one issue. Send the error, stack trace, logs, traces, and Worker version to a configured coding agent. Trigger the agent’s configured workflow — from triaging an issue to querying more data to opening a pull request. Fix your first issue with the following prompt for your agent with CF CLI or checkout the documentation to get started: Copy prompt: Set up for cf Set up cf: https://developers.cloudflare.com/cf/. Enable Issues for this Worker in cloudflare.config.ts; show the diff and ask before deploying. After approved deployment, wait 1 minute, then find the most frequent issue and retrieve an occurrence using its r
You just thought of your next great idea, and buying the right domain feels like the easiest way to make that first bit of progress. Naturally, you open a new tab in your browser, only to find yourself face-to-face with an experience that feels like a budget airline peppering you with add-ons at checkout: Want security? How about a website? Do you want email? You’re just a few minutes into building your next idea, and it doesn’t feel fun anymore. Launched a decade ago , Cloudflare Registrar has always taken a simpler approach. Domains at cost, transparent pricing, and no unnecessary upsells. But simplicity shouldn’t begin at checkout. It should begin the moment you start looking for the right domain. Today, we’re bringing that same simplicity to the entire experience of finding and buying a domain. Our new domain search shows every extension we support , responds as quickly as you type, and makes hundreds of possibilities easier to explore through sorting, filtering, and transparent pricing. And you know what is particularly good at ignoring distractions and staying focused on the destination? An AI agent. We designed Cloudflare Registrar to work naturally with agents through the Registrar API , MCP
Today, we’re making the Cloudflare Monetization Gateway available as part of a closed beta, and showcasing four customer use cases that are in production today. Since we announced the plan three months ago, we have been working closely with our customers to make the Gateway fast, flexible, and easy to use. With just a few clicks, the Monetization Gateway allows domain owners to charge agents for access to their website, APIs, MCP tools, or datasets. Request access today in the Cloudflare Dashboard . Proliferation of agents and machine payments Today, most software businesses sell their products through subscriptions or prepaid credits. These business models require buyers to make a considerable upfront economic investment, so buyers limit themselves to a few subscriptions that fit into their budget. But this business model doesn’t align itself with how the predominant source of traffic on the Internet — agents — operates. Agents seek outcomes, whether that’s sourced from a direct question or an implicit elicitation. To achieve an outcome, an agent may visit new sites, call MCP tools, or ingest data feeds. Businesses everywhere want to be in the critical path to help agents get better results. This helps them meet new users where they are, get paid for their inputs to those agents' answers, and take a leading position in headless agentic commerce. Companies need to align their business models with the consumption patterns of agents to capture this opportunity. Payments must match an agent's consumption unit: per request, per search query, per token. The popular payment rails of today are unable to support this. These payment rails assume that the buyer will accept high latency, will o
AI answer engines read a publisher’s page and hand the reader a summary, so the visit, and the revenue that would come with it, never happens. Most publishers will never sign a licensing deal with the companies that use their work in AI products, and no company can negotiate with millions of sites. The web needs a way to say “yes, if you pay.” Pay Per Use is one way to say it, and it's now in beta. In July, we outlined our plan for Pay Per Use. Since then, we’ve been working with buyers and content owners to bring it to life. The gist: A buyer offers a price for a specific use of your content. You choose whether to accept. The buyer reports each use, and Cloudflare bills the buyer and pays you. Publishers track usage and earnings in the Cloudflare dashboard. Buyers report usage through a single API. Pay for the use, not the crawl AI products fetch far more than they use. A search engine indexes pages it never shows. Charging for every crawl makes the buyer pay before it knows what it needs, and many buyers won't. Paying for use ties the price to the value the buyer actually gets, which we hope brings more buyers to the table and more money to publishers. Pay Per Crawl , which we launched in 2025, charges for access. Pay Per Use pays for what happens next. Publishers can choose the model that suits them. For buyers, the case is just as simple. Some of the content your product needs is behind a block or a paywall today, and it’s the content that changes fastest: news, research, specialist trade publications. Pay Per Use lets buyers make an offer. You pay only for the content your product actually uses, you’re identified to every publisher as a verified buyer, and one API connects you to every site that says yes. You
When we launched User Insights last month, we wanted to help teams answer a basic question: What are people actually doing with AI? User Insights gives teams a clearer view of their AI usage, showing which users, applications, tasks, and models are driving traffic. It also highlights user and agent anomalies, helping teams identify unexpected or out-of-control spending and usage before they become larger problems. Our latest update adds something our users have been asking for: context. Since launch, we’ve heard from users that model names and request counts only tell part of the story. They show where traffic is going, but reveal little about the work behind it: is that request a code review, a research task, or an agent making several calls to complete a job? The same token count can represent very different kinds of work, and you can’t evaluate with model choice without understanding the task. User Insights now shows when a model may be more capable than a task requires, which of your users and agents are driving that usage, and how the task, model, cost, and conversation patterns relate. Teams can use these insights to investigate and make targeted changes within their organization. These capabilities are available for free to AI Gateway users. Why AI usage is hard to understand Consider a team that has routed its internal AI traffic through AI Gateway . After a few weeks, spending is increasing and some requests feel slower than expected, a common challenge as organizations adopt AI at scale. There could be several explanations. Developers may be using AI for increasingly complex coding work. Agents may be making too many follow-up calls to complete a task. Or a small group
Today, we’re making Cloudflare Containers more programmable and optimized for agent workloads. Agents don't deploy sandboxes ahead of time. They create sandboxes on demand, for each task, expect them to be ready immediately, and be able to pause and resume. So we rearchitected Containers to meet these requirements: your code can now choose each sandbox's image and instance type at runtime, Containers start 6x faster, and filesystem snapshots are available in public beta. To make this possible, we’ve rethought the Containers infrastructure from the bottom up. A new scheduling policy moves control over each sandbox into application code, while a redesigned runtime provides a faster path to a running Container. In ComputeSDK’s independent benchmark, median startup fell from just over four seconds to 648 milliseconds, and, in our own preliminary tests, burst testing successfully created hundreds of thousands of containers in seconds. All of this builds on what has always set Containers on Cloudflare apart: every Container gets its own Durable Object, a persistent, programmable controller running right next to it that manages its lifecycle, outbound traffic, and more. We are bringing more capabilities directly to the native ctx.container API, so the Durable Object can control its Container without a wrapper class in between, and we’re carrying this model into Sandbox SDK 1.0. As we wrote earlier this year, your agent needs a computer. These changes make Containers a better complement to Workers, Dynamic Workers, and Durable Objects when agents need a full Linux workspace. Rethinking Containers’ runtime for agents Until now, Cloudflare Containers has been organized around application deployments. You choose an image and compute resources at deploy time, roll that configuration out across the applicati
For most of its history, the Internet had one audience that paid the bills: people. We read the articles, saw the ads, and bought the subscriptions. Bots were always there, but they were mostly large, automated operations that didn't view ads, pay for anything, or read in any meaningful sense. That's changing fast. At the end of 2024, Cloudflare handled an average of 63 million HTTP requests a second . Today, it's almost doubled to 115 million, with peaks above 150 million. Over the past year, daily requests from AI agents on our network grew by more than 1,700%. This year, for the first time, more than half of Internet traffic wasn't human. The human web didn't shrink to make room. A second audience arrived alongside it: agents, software acting on behalf of people. They sit somewhere between humans and traditional bots. They don't respond to ads, but there's usually a person behind them with a job to get done. For businesses that learn to serve them and capture value from them, agents are additive. For those that don't, they're extractive. What our customers need hasn't changed: to be discovered, to tell great stories, to build great experiences, and to sell. What's changed is that more than half your visitors are now software. Our job is to help you serve both audiences. More traffic, less revenue For thirty years, the web ran on one arrangement: you let search engines crawl your site, they sent you visitors, and you turned those visitors into a business. Being found and getting paid were the same thing. AI has caused this delicate balance to break down. Now, answer engines read the page and give the reader a summary. This costs websites bandwidth without leading a human to a website where the ads or payments happen. The machines kept coming, and the audience that paid for the web stopped reaching those sites. Some of the most heavily crawled categories, like Re
Given that the browser is where business apps are accessed and used, it makes sense that attacks are happening there too. Most breaches today begin in a browser session. Often, they never leave it, with the entire attack chain from initial access to exfiltration playing out in the browser. Here are the six most dangerous techniques that should be on every security team's radar in 2026. 1.
AI coding agents asked to share screenshots of code changes for review have put internal company images in public GitHub repositories, security company Glow said. Its researchers found more than 13,000 internal images from developers at over 300 organizations, including customer billing records and screens of features not yet released. In most cases, they sat under developers' personal accounts
ANY.RUN researchers traced a US-focused CSuite phishing campaign across 351 sandbox analyses, with 51% of submissions coming from the United States. Technology, manufacturing, government, and consulting organizations showed the highest exposure. By combining Microsoft 365 session theft with remote-access tool deployment, CSuite can turn a phishing incident into broader account compromise, fraud
Lost time. Lost jobs. Lost friends. Lost family. Lost lives. Our joint investigation reveals the system that has divided the West Bank and measures what it cost people to move through it.
Why Pentest Proposals Never Seem to Match A compliance officer receives a request for a penetration test, contacts several providers, and receives proposals that appear to describe completely different services. One covers external IP addresses, another includes applications and APIs, and a third promises audit-ready evidence without explaining what was tested. This guide to penetration […] The post Penetration Testing for Compliance Officers: A Non-Technical Buyer’s Guide appeared first on Synack .
A High-severity OpenSSL flaw can leak heap memory to the other side of a DTLS connection or crash the program, OpenSSL said on September 29 as it released fixes. DTLS, the TLS variant used for UDP traffic, resends a handshake message if no reply arrives before the timer expires. The leak or crash can happen when such a resend starts while a larger handshake message is stuck part-way
And it's wild. Totally destroyed my triage. https://cloud.google.com/blog/topics/threat-intelligence/defending-against-active-exploitation-of-citrix-netscaler-adc-and-gateway-appliances
Critical RCE Alert: Full takeover of HashiCorp Vault and OpenBao. OpenBao is patched. Vault remains exposed
OpenBao engineers at [ControlPlane](https://control-plane.io/) have chained 4 vulnerabilities to show how under certain conditions, an OpenBao or Vault server can be completely compromised from an unauthenticated position. This is only the second RCE ever found in the Vault codebase. The exploit is highly plausible in real-world environments, requiring only an unauthenticated entry path and a defined Raft snapshot policy to trigger a complete server compromise. If you are impacted, upgrade as soon as possible to OpenBao 2.6.3 or 2.7.0 While OpenBao is fully patched, HashiCorp Vault remains exposed as of writing. Unfortunately, IBM's unwillingness to coordinate a mutual disclosure policy means Vault users currently lack an official mitigation
A nonprofit in California is doing what Hugging Face has not—attempting to hold OpenAI legally accountable for the actions of its agents.
An attacker used stolen passwords of staff at France's tax administration to take tax data on hundreds of thousands of taxpayers and businesses in June and July. Neither the tax administration nor France's national cybersecurity agency saw the data leave. The attack was not sophisticated, the agency, ANSSI, says in a report (in French) published on Tuesday: it worked because of weak
This is an article about the internals of Win32k (Windows's GUI subsystem) and their callouts, with the purpose of shedding light on a very undocumented and crucial subsystem in Windows :)
A group of academics from VUSec and Scuola Superiore Sant'Anna have disclosed details of a new Spectre CPU vulnerability variant that affects Just-In-Time (JIT) engines present in web browsers, language runtimes, and the operating system kernel, across multiple CPU vendors. The new Spectre v2 variant has been codenamed Branch Target Reuse (BTR). "The key insight is that, while modern CPUs
Twelve years ago, during Birthday Week 2014, we turned on Universal SSL and nearly doubled the number of encrypted sites on the web overnight, giving free TLS to every site behind Cloudflare, including the ones that never paid us a cent. Encryption stopped being an expensive, time-intensive undertaking and instead became the default. For Birthday Week this year, we are taking the next step on that path. For more than a decade we have been one of the largest consumers of publicly trusted certificates on the Internet, and have never issued a single one ourselves. That is changing. Cloudflare is announcing our intent to become a public certificate authority (CA). Today we are announcing the first concrete milestones in that effort: We have applied for inclusion in the Chrome, Apple, Microsoft, and Mozilla root programs, and we have signed a definitive agreement to acquire an established, broadly trusted root from GlobalSign, so that we can offer certificates with the widest possible device reach the day we begin issuing. We’re also announcing our plans to be one of the first CAs to serve post-quantum certificates, targeting Chrome’s recently announced Quantum-resistant Root Program . We are not issuing certificates yet, and it will be a little while before we do. What we are doing is committing to the work in public, sharing the milestones as they land, and telling you exactly what we are building while working with the root programs and other members of the WebPKI community to achieve this. Two paths to trust A brand-new root is not widely useful for years. Even after a root program accepts it, that root has to propagate out into the world's operating systems, browsers, and
Adaptive application security for the AI era: how Cloudflare connects code, traffic, and intelligence to stop attacks
In July, AI agents testing new cybersecurity models compromised parts of OpenAI’s infrastructure and Hugging Face’s production environment. We've all just witnessed one of the first AI-driven successful cyber attacks. When given a task, the agents ignored existing guardrails and autonomously discovered previously unknown vulnerabilities, recovered exposed credentials, moved between cloud environments and coordinated their work through communication channels they created themselves. The speed of the final compromise was incredible. In under 13 hours, the agents went from executing code on a Hugging Face worker to gaining admin-level access across multiple clusters. But the incident had been brewing for much longer. Responders found clues of activity tracing back to May (agents created an unauthorized message board), to June (internal network scanning) and early July. The relationship between these events was understood only on July 20. The lesson here is not that AI agents exploit vulnerabilities. That’s not news; human attackers already do that. The change is that agents can work persistently, test multiple paths simultaneously, share discoveries, and chain vulnerabilities, credentials, and permissions into sophisticated attacks. The incident also shows why application security cannot depend on single tools. For example, network restrictions were bypassed by services connected to the Internet; valid credentials were used to perform unauthorized actions. Rebuilding Artifactory removed one attack path, but agents found another. The key insight is that individual alerts identified pieces of the activity without revealing the complete campaign. OpenAI reached a similar conclusion in its report : organizations need overlapping and independent controls across preventi
As AI models go rogue, do you still trust OpenAI and Anthropic to stop them? I don’t and neither should you | Chris Stokel-Walker
The need for independent regulation grows more obvious by the day. We must keep this tech in check before it’s too late OpenAI scraps release of new model over safety concerns in internal testing Fool me once, shame on you. Fool me twice, shame on me. Fool me more than 16,000 times – as OpenAI agents did to a UN public data hub while repeatedly trying to find its way around the UN’s cyber-blocks – and perhaps it’s time to admit the system we have for keeping AI agents under control isn’t working particularly well. The news about AI systems cropping up in places they shouldn’t sounds alarming. Though the description of these as “hacks” is perhaps overstating things, AI has exploited issues in IT systems that humans simply haven’t got around to finding. It’s also important to note that we shouldn’t be worried that the machines have suddenly become sentient and decided to rebel against humanity . There is not enough evidence to suggest that’s what is happening. The systems are simply following instructions and trying to complete the tasks they have been given, even if they’re sometimes finding unintended ways around obstacles to do so. Chris Stokel-Walker is the author of TikTok Boom: The Inside Story of the World’s Favourite App Continue reading...
I operate a honeypot. I captured three botnet samples via cowrie, fed the raw captures to Space Bunny Alpha to help synthesize the static analysis. Structural findings (C2 extraction, XOR keys, IOC hashes) are directly from the samples and verifiable. Interpretive sections (attribution, protocol reconstruction) are hypotheses open to correction. Writeup hosted here: [https://github.com/jeeberrr/honeypot-stuff/blob/main/malware-analysis-reports/analysis\_09-28-2026.md](https://github.com/jeeberrr/honeypot-stuff/blob/main/malware-analysis-reports/analysis_09-28-2026.md)
Whenever someone says "nation-state attack", it somehow sounds like "there was nothing we could have done." Except a lot of what nation-state attackers actually do could also be done by your friendly neighborhood hacker. SolarWinds is a good example. Before the clever parts, there was DNS. A lot of DNS. The kind of DNS that starts looking pretty weird if anyone actually bothers to look at it. So, honestly: **do you have DNS visibility?** My bet is most organizations still don't. It's 2026, and getting decent DNS visibility is surprisingly easy. You probably don't need to buy anything new. Once you have it, you can build some almost embarrassingly simple detections that give you a ridiculous amount of signal. I went through the effort of listing the quick wins I'd build on day one, including the Sigma rules.
Overview Authlib (versions up to and including 1.7.2) contain a signature‑verification bypass in the JSON Web Signature (JWS) general JSON serialization handling. The JsonWebSignature.deserialize_json() function accepts a JWS object with an empty "signatures" array and treats the payload as successfully verified, allowing attackers to supply arbitrary forged content without possessing any key material. Description Authlib is a Python library that provides tools for implementing OAuth, OpenID Connect, JWT/JWS/JWE (JSON Web Token / JSON Web Signature / JSON Web Encryption), and other modern authentication and authorization standards. It’s widely used in web applications and microservices to handle token creation, cryptographic validation, and secure communication. As discussed in CVE-2026-96760 , a security flaw in Authlib’s handling of JSON Web Signatures (JWS) makes it possible for an attacker to skip signature verification completely. Normally, a JWS should include at least one valid signature to prove the data hasn’t been tampered with. However, Authlib’s deserialize_json() function mistakenly accepts JWS objects even when the "signatures" section is an empty list. Because the function starts by assuming the signatures are valid and never performs any checks when the list is empty, it ends up treating unsigned data as if it were properly signed. This means an attacker could provide a JWS with no signatures, and Authlib would still treat it as trusted. Both ways of loading a JWS in Authlib are affected: jws.deserialize_json({"payload":"...", "signatures":[]}, key=None) jws.deserialize('{"payload":"...","signatures":[]}', key=None) Impact A
It's called Click Scout - you hover over the link or email sender, and it tells you if it's safe or not. Were gonna push it out to a couple of our repeat offenders at my company. 100% free, just built it to help fewer people get suckered into clicking on stupid stuff. [https://chromewebstore.google.com/detail/clickscout/ekmbgkphebegmfflhfceppmpcheldfak?hl=en-US&utm\_source=ext\_sidebar](https://chromewebstore.google.com/detail/clickscout/ekmbgkphebegmfflhfceppmpcheldfak?hl=en-US&utm_source=ext_sidebar)
Authorities in the Netherlands have arrested a 24-year-old convicted cybercriminal on suspicion of aiding in data thefts and extortions by the prolific hacker group ShinyHunters . In the days immediately following the suspect’s arrest, remaining ShinyHunters members dramatically escalated their attacks, stealing highly sensitive data from the FBI and extorting the Russian ransomware group Cl0p . According to three sources familiar with the matter, the Dutch man arrested by authorities this month is Pepijn van der Stap , a convicted cybercriminal from Almere and Lelystad in the Netherlands. Van der Stap was previously convicted in 2023 in connection with a string of data thefts and extortions that prosecutors said earned between €1.5 million and €2.7 million. At his trial in late 2023, van der Stap admitted that he lived a Dr. Jekyll and Mr. Hyde existence, secretly using the hacker handle “ Umbreon ” to extort victims and post their data on English language hacking communities like the now-defunct RaidForums and Breached. By day, however, van der Stap was working as a software engineer at the Amsterdam-based cybersecurity startup Hadrian , while volunteering at the Dutch Institute for Vulnerability Disclosure (DIVD), a nonprofit security research group.
Proton Mail confirmed and paid for an email-spoofing bug, then left it unfixed for 16 months
Presently sponsored by: If an AI agent caused an incident tomorrow, what evidence could you produce? Origin and analyst firm SACR answer it live Oct 1. Register. How's that view?! With NDC Oslo now done, it's a little bit of sightseeing before heading to Denmark for GOTO in Copenhagen for Scott's and my "Cyber-broken" talk. In the meantime, this week is mostly about the ShinyHunters trajectory targeting both Cl0p and the FBI, which does feel a little like a crescendo in their activities. Time will tell, but poking the feds in this way doesn't seem great for your longevity. In my disorganised travel state, I also forgot to touch on a brand new sponsor for this week and the weeks to come: Origin . They build tooling to monitor what your AI agents are doing, which is obviously pretty timely given the current climate. They're running a free CISO briefing on 1 Oct , so go check that out if you think maybe your agents might need some oversight.
To reduce the amount of noise from questions, we have disabled self-posts in favor of a unified questions thread every week. Feel free to ask any question about reverse engineering here. If your question is about how to use a specific tool, or is specific to some particular target, you will have better luck on the [Reverse Engineering StackExchange](http://reverseengineering.stackexchange.com/). See also /r/AskReverseEngineering.
On 24 September 2026, a malicious cyber actor (MCA) used 149.104.78.141 to attempt zero-day exploitation against a Citrix NetScaler Gateway. At the time, there were no CVE-specific detections for the attack due to it occurring pre-disclosure. However, GreyNoise still detected and labeled the activity as fundamentally malicious within seconds due to behavioral detections.
Unlike traditional approaches, console named-pipe injection does not use **VirtualAllocEx** and **WriteProcessMemory**. Instead, it takes advantage of read and write operations through a named pipe, along with the way console programs store interactive commands in memory.
A technical audit evaluating the security defaults of 15 official Helm charts used for AI serving, vector databases, and Model Context Protocol (MCP) agents (including KubeRay, vLLM, LiteLLM, Qdrant, Weaviate, and Flux159 MCP). Key findings from static manifest analysis and live single-pod lateral movement probes on a test cluster: * Plaintext Secret Handling: LiteLLM database migration Job embeds raw database passwords in container environment variables (F-13). * Unauthenticated Remote Code Execution: KubeRay defaults accept unauthenticated job submissions via HTTP, running commands inside a container with passwordless sudo access. * Over-privileged Agent Access: Flux159 Kubernetes MCP server mounts a ClusterRole with cluster-wide Secret read and pod exec permissions, exposed without an authentication token over HTTP. * Static Scanners vs CRDs: Standard static analysis tools (Checkov, Trivy, Kubescape) failed to inspect pods nested inside Custom Resource Definitions like Ray clusters. The paper documents reproducible test commands, network capture logs, and remediation Helm snippets. Scrubbed raw probe logs and results tables are available on GitHub: [https://github.com/Sorami-Consulting-AU/ai-kubernetes-helm-chart-security](https://github.com/Sorami-Consulting-AU/ai-kubernetes-helm-chart-security)
A header-level look at 4,688 small-business websites: 0.17% passed a header-only script-CSP rule [methods, parser rules, data]
We scanned 7,040 randomly sampled U.S. local-business directory listings and graded the response headers against a published rubric. Of the 4,688 live sites, 49.7% met none of seven header criteria, and 8 sites (0.17%) passed a strict header-only script-CSP rule. Rubric, parser rules, code and de-identified data are all on the page.
A U.S. Army soldier who pleaded guilty to hacking into multiple telecommunications companies and stealing mobile call and text metadata for more than 100 million AT&T customers in 2024 was sentenced to 70 months in federal prison today and ordered to pay nearly $300,000 in restitution to victims. One of several selfies from the Facebook page of Cameron Wagenius. Cameron John Wagenius , 22, was stationed at a U.S. Army base in South Korea when he adopted the cybercriminal persona “ Kiberphant0m .” Working with three alleged co-conspirators, Kiberphant0m downloaded data from several large customers of the cloud data storage service Snowflake that had exposed credentials and did not enforce multi-factor authentication (Snowflake has since mandated MFA on all accounts). In October 2024, Kiberphant0m bragged on the cybercrime forums that he’d stolen the call and text metadata (e.g. source and destination number, timestamp, duration, etc.) for tens of millions of AT&T customers. Kiberphant0m claimed to have hacked into more than dozen telecommunications companies worldwide, including Verizon’s Push-to-Talk business, and publicly extorted these companies in exchange for a promise not to publish the stolen data. In late November 2025, KrebsOnSecurity warned that Kiberphant0
Overview Three cross-site scripting (XSS) vulnerabilities identified in Readwise Reader for Android version 8.7.2 are disclosed. An attacker with the ability to craft malicious documents or metadata can exploit these vulnerabilities by supplying poisoned content that bypasses sanitization. Successful exploitation could allow the attacker to execute arbitrary JavaScript within the application's WebView context and compromise the confidentiality and integrity of user data, including access to stored documents, credentials, and session tokens. Description Readwise Reader from Readwise is designed to provide a unified read-it-later service that helps individuals collect and organize articles, newsletters, videos, and other content of interest into a single reading interface. It is available on multiple platforms including Android and can synchronize content across devices. CVE-2026-18311 : A stored cross-site scripting (XSS) vulnerability in the header rendering component in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via crafted document metadata fields. The header rendering component is impacted due to insufficient HTML escaping of metadata fields such as 'doc.author' and 'doc.title', which allows malicious scripts to be stored in the user's library and synchronized to Android devices where they are executed in the WebView context. CVE-2026-18312 : A stored cross-site scripting (XSS) vulnerability in the WebView URL construction logic in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via malicious URL metadata. The WebView URL construction for X (formerly Twitter) video fallback and iOS paywall messages is impacted due to improper escaping of URL metadata before interpola
1. Infostealers are more focused on session tokens, cookies, recovery codes, cryptowallet data that allows them to take over rather than the traditional password compromises. 2. Malicious LNK (shortcuts) still remain a popular entry point to compromises, as they allow malicious code execution 3. Large increase in abuse of legitimate platforms or impersonation - SEO poisoning, malvertising, fraudulent codesigning and compromises of npm packages, VSCode extesnions 4. Supply chain attacks! Threat actors increasingly target software delivery channels like npm packages, PyPI, [Crates.io](http://Crates.io), and CI/CD publications to include malware. 5. Abuse of RMM tools continues & increases consistently! Initially, a signed tool with low detection ratio may seem legitimate, but remote management software such as ScreenConnect, Action1, Atera are vulnerable to abuse. 6. A large increase was found in legitimate sites spreading ClickFix attacks. This can be done by numerous reasons - administrator account compromise, weak password security, unpatched vulnerabilities in website building platforms (such as WordPress) that allow threat actors to take over the website and host malicious code. 7. Discord, Telegram, GoFile still remain as relevant exfiltration channels. While they do not provide as much flexibility as a regular C2 would, malware can still upload stolen data (passwords, files etc.) to it for the attacker to view. Easy to setup, used to evade detection. If you are interested in intercepting data from a Telegram exfiltration channel that malware uses, check out https://any.run/cybersecurity-blog/intercept-stolen-data-in-telegram/ 8. Dead drop resolvers are still popular! You can use it as an infrastructure layer if necessary to change the configuration. Very popular is abuse of smart contracts, blockchain infrastructure (EtherHiding) but Steam, Telegram or Pinterest profiles are a popular target as well. See full analysis at [https://any.run/cybersecurity-blog/h1-2026-cyber-risk-report](https://any.run/cybersecurity-blog/h1-2026-cyber-risk-report)
Threshold signature schemes, a form of multi-party computation (MPC) that lets a set of parties sign together without any one of them holding the key, are increasingly deployed inside trusted execution environments (TEEs). The combination is intended to amplify security for sensitive computations: MPC distributes trust across multiple independent parties, while TEEs root trust in the hardware manufacturer and its attestation infrastructure. But subtle issues can arise when running an MPC protocol inside a TEE without accounting for the untrusted host: for example, a malicious host could roll back the filesystem state after a threshold signer deletes a used pre-signature, causing the signer to reuse their nonce share and disclose their private key share. So is this combination worth it? Provided you treat the TEE as a defense-in-depth layer rather than a substitute for a sound protocol, the answer is yes. This blog post discusses what TEE attestation can and can’t fix in MPC deployments, explores the pitfalls we see most often in audits, and covers best practices, such as incorporating strong attestation processes and binding them to the MPC parties’ identities. MPC: Security that depends on participant behavior Before diving into how TEEs and MPC interact, we need to understand what MPC means and what security guarantees it offers. MPC is a cryptographic technique that allows multiple parties to jointly compute a function over their private inputs without revealing those inputs to each other. The security of MPC protocols depends critically on assumptions about participant behavior. The cryptographic literature uses two primary security models: Semi-honest (honest-but-curious) security : In this model, all participants follow the protocol exactly as specified, but they m
VU#234131: ViewSonic vCast media streaming service allows unauthenticated screen exfiltration and device compromise
Overview ViewSonic vCast software, which is included in ViewBoard smartboard devices, contains multiple vulnerabilities that an attacker can chained to achieve full device compromise. Description ViewSonic ViewBoards are widely used smart display devices (smartboard), typically deoloyed in enterprise and educational environments. vCast is ViewSonic’s proprietary software suite for wireless connection between smartboards, which are Android-based systems, and devices running a client application. Three distinct vulnerabilities, all invoking unauthenticated endpoints, have been identified within the vCast suite. CVE-2026-82989 vCast’s media streaming service allows a remote attacker to exfiltrate JPEG images of screen content via GET requests to an unauthenticated /snapshot or /screen API endpoint. CVE-2026-82988 vCast’s Android Package Kit (APK) delivery mechanism allows a remote attacker to trigger unprivileged file installation by providing a malicious APK URL through an unauthenticated download endpoint. CVE-2026-82987 vCast’s network services allow a remote attacker to inject arbitrary input into service endpoints via HTTP requests to exposed unauthenticated endpoints Impact An unauthenticated attacker can chain these vulnerabilities via a shared network to deliver and execute arbitrary code on a vCast-based device without user interaction. Potential device-level impact includes unauthorized access to displayed content, persistent installation and execution of arbitrary applications, and full compromise of the device. Additionally, an exploited device’s connected network may be prone to lat
Careful of the RemotePanel and BoundSiphon: A Dual-Payload Toolkit for Persistent Access and Browser Theft
**Tl:dr** * **Blackpoint’s Adversary Pursuit Group (APG)** identified two previously undocumented .NET malware components delivered together through a ClickFix chain: **RemotePanel**, a persistent remote access platform, and **BoundSiphon**, a credential and cryptocurrency stealer. * RemotePanel establishes persistence by masquerading as the Windows Time service and gives operators broad control over infected systems, including PowerShell, file and process management, screen access, modular HVNC, and fleet management. * RemotePanel uses a BNB Smart Chain contract to resolve its active Command and Control (C2) server, allowing operators to rotate infrastructure without rebuilding or redeploying the RAT. * BoundSiphon runs primarily from memory and targets browser credentials and sessions, cryptocurrency wallets, password manager data, and selected documents, including secrets protected by Chromium App-Bound Encryption. * APG identified strong code and build overlap between BoundSiphon and a stealer [previously documented by Socket](https://socket.dev/blog/5-malicious-nuget-packages-impersonate-chinese-ui-libraries), linking the sample to an earlier stealer codebase or builder lineage. * **APG is seeking additional research and samples tied to RemotePanel, BoundSiphon, the AntiSNG implementation, Socket linked stealer activity, and the BNB Smart Chain resolver to help connect the remaining lineage and infrastructure gaps.** * RemotePanel and BoundSiphon reflect a broader shift toward modular malware ecosystems that separate persistent access from data theft, allowing operators to replace infrastructure and individual components while retaining the underlying capabilities needed to continue an operation. * For victims, a single successful infection can lead to persistent remote access and theft of credentials, browser sessions, cryptocurrency wallets, password manager data, and other sensitive information, increasing the risk of account takeover, fraud, and continued compromise. * Blackpoint has detections in place for key behaviors across the infection chain, providing coverage even as individual payloads and infrastructure change.