Prepared by: Triskele Labs Offensive Team | Published: 13 October, 2026
The Offensive team at Triskele Labs is recognised as an industry leader in identifying and sharing critical vulnerability insights on both local and global scales. Supported by highly qualified specialists, we conduct in-depth trend analyses to ensure comprehensive coverage of both established and emerging techniques within the continually evolving threat landscape. Our expert penetration testers work to verify the security of clients' networks and environments, both physical and virtual, revealing potential entry points before malicious actors can exploit them and providing clear, prioritised and actionable recommendations for remediation.
OFFENSIVE SECURITY · STATE OF CYBER 2026
Testing across 355 engagements this year turned up a consistent pattern: the most damaging failures weren't exotic vulnerabilities. They were controls that existed on paper but had never been tested against a determined attacker.
What changed this year:
Key Findings:
What you'll learn in this article: why identity, not exploit code, is the through-line across this year's most serious findings, how AI is now used on both sides of an assessment, why Critical findings concentrated in segmentation and banking software rather than spreading across the client base, and what the first quantified retest results show about whether testing drives improvement.
During the 2026 financial year, the Triskele Labs Offensive team conducted 355 engagements across approximately 139 organisations, spanning Financial Services, Healthcare and Life Sciences, Government and Public Sector, Industrial and Resources, Retail, Technology, Education and the not-for-profit community. While this is fewer engagements than our previous report, the engagements themselves were longer, so the total days spent testing were very similar year on year, with our team size remaining relatively static. Across these assessments we identified 2,705 vulnerabilities, an average of 7.6 per engagement and close to eleven new findings on every business day of the year. Our testers spent 1,857 days on the tools, meaning the average engagement represented a full working week of dedicated, expert-led assessment.
“...close to eleven new findings on every business day of the year.”
The headline pattern from last year holds: the volume of security issues is driven overwhelmingly by configuration and hygiene weaknesses rather than exotic exploits, while the most dangerous findings cluster tightly around identity and internal network architecture. Critical findings remained rare at 0.8 per cent of all issues, and were concentrated in a small number of operational technology and banking environments rather than spread evenly across our client base.
Every finding is assigned a risk rating using the Triskele Labs custom risk framework so that clients can prioritise remediation. Tracking the severity distribution across three reporting periods shows a remarkably stable risk profile, which is itself the story: despite a growing and more diverse client base, the shape of what we find has barely shifted.
| Severity | Prior to FY2025 | FY2025 | FY2026 |
|---|---|---|---|
| Critical | 0.8% | 0.3% | 0.8% |
| High | 8.3% | 8.0% | 8.7% |
| Medium | 24.1% | 22.8% | 26.5% |
| Low | 51.4% | 54.2% | 50.6% |
| Informational | 15.4% | 14.8% | 13.4% |
The Critical share returned to 0.8 per cent this year after the previous period's dip to 0.3 per cent. This is not a sign of deteriorating client security. The Critical findings this year were concentrated in two areas. The larger share related to a lack of network segmentation, an issue we continue to see across many clients whose networks remain flat and insufficiently segmented, and which repeatedly gives an attacker who gains a foothold the freedom to move. The remainder were highly technical, critical-impact flaws in banking software, including race conditions in transaction authorisation. These emerge from a particular strength of ours: we work with a large contingent of financial institutions, many of which run the same underlying platforms, and that concentration has given us a deep understanding of those products, deep enough to surface serious flaws that only come to light with expert-level knowledge of the product. Stripped of these clusters, the underlying rate of Critical findings across the general client base remains very low and consistent with prior years.
Engagement volume grew steadily across the year, with a pronounced peak in October and sustained activity through the second half. Plotting engagements against findings shows the two move broadly together (correlation 0.86), but not perfectly. Findings density per engagement was highest in the first quarter of the financial year and again in April, and lowest through the December and January holiday period, reflecting both the type of work scheduled and the maturity of the environments tested in each window.
Engagements and findings by month, 2025-26.
Two patterns drive this seasonality. Many clients purchase penetration testing in June to meet end-of-financial-year compliance targets and to use remaining budget, a standard trend across many sectors. Many others want testing completed before Christmas, producing the end-of-calendar-year rush, whether to have confidence in their platforms across the holiday break or simply to close the task off before year's end. The practical implication for clients is capacity planning: testing demand concentrates around these windows, and organisations that book early avoid the queue.
Consistent with previous years, web application testing dominated our workload, followed by external and internal network assessments. Quantifying the mix for the first time:
| Test type | Share |
|---|---|
| Web application | 43% |
| External network | 14% |
| Internal network | 11% |
| Mobile application | 9% |
| Cloud and configuration review | 5% |
| Wireless | 3% |
| API (standalone) | 3% |
| Operational technology | 2% |
| Open Banking | 2% |
| Configuration and SOE review | 2% |
| Red team and assumed breach | 2% |
| AI and LLM assessment | 1% |
| Other (social engineering, thick client, code review, hardware) | 3% |
Test type mix, 2025-26.
Web applications and their APIs continue to make up close to half of all testing, a reflection of how much business logic and customer data now lives in browser-delivered software. We have split out Open Banking as its own category for this report; it is not new work for us, as we delivered plenty of it in prior years without separating it in our reporting. What is true is that more of this testing is occurring, driven by the New Payments Platform, the Consumer Data Right and the continued expansion of financial-platform connectivity and regulation.
Volume statistics can mislead. The most common findings overall are low-impact hygiene issues such as missing security response headers and outdated JavaScript libraries. They are worth fixing, but they are rarely how an attacker takes control. To show where real risk sits, we ranked the High and Critical findings recorded this year, setting aside those whose frequency simply reflects repeated detection within individual internal networks. What remains is a set of issues that recur across many different clients and test types.
| Rank | Finding |
|---|---|
| 1 | Default Credentials |
| 2 | Local Administrator Account Password Reuse |
| 3 | Sensitive Network Shares Accessible to Authenticated Users |
| 4 | Insecure Direct Object Reference (IDOR) |
| 5 | Missing Authorisation Checks |
The pattern is unmistakable. Every finding on this list is a failure of either credential management or authorisation, and not one is a novel software vulnerability. The first three concern who can gain access and how far that access reaches: predictable default credentials, reused local administrator passwords that enable lateral movement, and sensitive data left readable to any authenticated user. The last two, insecure direct object references and missing authorisation checks, are the web and API equivalents of the same failing, where an application authenticates a user but never properly verifies what that user is permitted to see or do. The organisations most exposed to serious compromise this year were not those running vulnerable code, but those that had not answered two basic questions: who can log in, and what are they allowed to do once they have.
If there is one theme that runs through this year's most serious findings, it is that identity remains the primary path to compromise. Across our engagements we repeatedly gained or escalated access not by exploiting a software flaw, but by taking advantage of predictable, reused or unprotected credentials.
The evidence is consistent across every layer of testing. A lack of multi-factor authentication on systems that should have required it was among our most frequently identified issues. Default credentials, insecure password rotation practices, local administrator password reuse and unprotected privileged domain accounts appear repeatedly among our High and Critical findings. On internal networks, the combination of reused local administrator passwords and accessible network shares routinely allowed our testers to move laterally and reach sensitive data. In several red team engagements, employee accounts were taken over through social engineering, bypassing technical controls entirely.
The lesson has not changed, but it bears repeating because organisations continue to under-invest here. Multi-factor authentication, ideally phishing-resistant, unique and well-managed credentials, tiered administrative accounts and disciplined privileged access management remain the highest-return security investments an organisation can make. Phishing-resistant MFA in particular is increasingly important and is progressively being mandated by security frameworks, including the Essential Eight. These controls defend against the exact techniques that dominate our most severe findings, and they cost a fraction of the tooling that many organisations buy instead.
Because we test across the Australian economy, we can compare how different sectors fare. The table below groups engagements by client sector.
| Sector | Share of clients | Share of engagements | Findings per engagement | High and Critical share |
|---|---|---|---|---|
| Financial Services | 40% | 38% | 7.3 | 8.6% |
| Technology and Software | 14% | 19% | 7.5 | 7.5% |
| Healthcare and Life Sciences | 13% | 12% | 7.1 | 5.5% |
| Retail and Consumer | 8% | 8% | 8.1 | 10.5% |
| Industrial, Energy and Resources | 7% | 8% | 16.0 | 21.0% |
| Education and Non-Profit | 10% | 10% | 6.6 | 3.6% |
| Government and Public Sector | 7% | 6% | 8.6 | 14.5% |
High and Critical finding share by sector, 2025-26.
Financial Services is our largest and most frequently tested sector, and its results reflect that maturity: a findings density at the overall average and a moderate proportion of serious issues, consistent with organisations that test regularly and act on the results.
The clear outlier is Industrial, Energy and Resources, where engagements produced more than twice the average number of findings and where one in five was High or Critical. This is driven substantially by operational technology environments, which are frequently built for reliability and longevity rather than security, and which often lack the segmentation and patching discipline of corporate IT. As transport, utilities and resources organisations connect more of this technology to their networks, the gap between OT and IT security is becoming one of the most significant exposures we see.
Government and Public Sector also warrants attention, with a higher-than-average share of serious findings across a smaller number of engagements. Education and the not-for-profit sector recorded the lowest severity profile, reflecting simpler and largely web-facing attack surfaces.
Last year we noted the rise of artificial intelligence in both the building and the breaking of software. This year, for the first time, we conducted dedicated penetration tests of AI and LLM-powered applications, including customer-facing AI chatbots, AI assistants and agentic automation platforms.
These engagements confirmed that AI-enabled applications introduce a distinct class of risk that traditional testing does not fully cover. Beyond the conventional web and API vulnerabilities that still apply, we assess for prompt injection, where crafted input manipulates the model into ignoring its instructions; excessive agency, where an AI assistant is granted more access or autonomy than its task requires; sensitive data exposure through model responses; and weaknesses in the automation and integration layers that connect these models to business systems. The rapid adoption of tools that let a model take actions, not just answer questions, significantly expands the potential impact of these flaws.
Our guidance to organisations deploying AI is to treat it as they would any other internet-facing application handling sensitive data, and then some. The underlying platforms are new, changing quickly, and frequently assembled from components that prioritise a working demonstration over a secure design. Before deployment, organisations should understand what data the model can reach, what actions it can take, and what happens when a user deliberately tries to make it misbehave. We expect demand for this style of testing to grow substantially in the coming year.
External network testing continues to surface a consistent set of internet-facing weaknesses. The most common issues we identify on the perimeter are missing or misconfigured security response headers, information disclosure through verbose server responses and error messages, weak content security policies, exposed administrative interfaces and unencrypted services. Thirty engagements this year identified an administrative interface exposed to the internet, and outdated or vulnerable software remains a recurring perimeter finding.
Individually, many of these are rated low or medium. Collectively, they hand an attacker the reconnaissance and footholds that make a serious intrusion possible: an exposed admin panel with weak authentication, or a forgotten host running outdated software, is often the first link in a chain that ends in compromise. Maintaining an accurate inventory of internet-facing assets, and testing them regularly, remains the most effective way to shrink this attack surface.
The urgency of this has increased. The arrival of frontier AI models with real offensive capability, of the kind now emerging in the market, heightens the risk posed by external attack surface exposure. Where reconnaissance and initial exploitation once required attacker time and skill, these platforms allow adversaries to consume publicly available information and probe for security flaws at mass scale, faster and cheaper than before. Weaknesses that were previously unlikely to be found simply because no human got around to looking are now far more likely to be discovered and exploited. Reducing the amount of information and unnecessary exposure an organisation presents to the internet is no longer just good hygiene; it is a direct defence against automated, AI-driven attacks.
The statistics describe the shape of the year. These three engagements show what the work actually looks like, and where the offensive landscape is shifting. Each has been anonymised.
On the back of a client engagement to test a web application that let users connect to a range of data sources through Java Database Connectivity (JDBC) drivers, our team turned its attention to the driver implementations themselves. Reviewing the decompiled source of a widely used commercial database connector, our consultants identified two previously unknown vulnerabilities: an arbitrary file write and an arbitrary class loading flaw, each capable of achieving remote code execution and full compromise of the host web server. Both were responsibly disclosed to the vendor, assigned CVE identifiers (CVE-2025-10702 and CVE-2025-10703), patched, and published through a coordinated disclosure process. The affected connectors are deployed across a very large number of enterprise environments worldwide.
The engagement is a window into how the exploitation landscape has changed. Artificial intelligence has become very good at finding bugs in code. So good, in fact, that for our offensive team the hardest part of exploitation is increasingly not the analysis itself, but getting hold of the code in the first place. Given source or decompiled code, AI-assisted review can surface exploitable logic flaws far faster and more reliably than was possible even a year ago. Without the code, AI can still find vulnerabilities. Recent incidents have shown frontier models autonomously discovering and chaining flaws in live systems with no source-code access at all. But doing so against an external, black-box target currently demands enormous computational effort, which keeps it slow and expensive at scale. Given the code, that same analysis becomes fast, cheap and repeatable, which is why access to it remains the decisive factor.
This distinction now shapes how we work. It is the reason source-code and decompilation review is becoming central to how we scope engagements and prioritise testing effort, rather than an optional add-on. It is also reshaping the economics of bug bounties: where a researcher can obtain the underlying code, the probability of finding a serious, exploitable flaw has risen sharply. Organisations should assume that any code an attacker can reach, whether through a leak, a decompiled mobile or desktop application, or an exposed repository, is now materially more dangerous than it was. Protecting source code, and proactively reviewing your own before an adversary does, has become a front-line control.
An organisation operating across multiple physical sites engaged us to emulate a specific, active threat actor known for targeting service desks through social engineering. Over a series of telephone calls, our consultant impersonated a legitimate employee using AI voice modulation, supported by identity details assembled from public sources and dark-web breach data, including a date of birth recovered from a leaked password. Preliminary calls to individual sites established the internal escalation paths, the target's work location and the relevant contact numbers. Using that groundwork, the consultant worked payroll and the IT service desk in sequence, changing the phone number on file, establishing a false trust anchor, and ultimately convincing the service desk to issue new login credentials to an attacker-controlled email address, all without ever meeting the employee or their manager. The result was a full account takeover achieved entirely through human process abuse, rated Critical.
What makes this engagement notable is not the technique, which is well established, but the role AI now plays in making it convincing. Voice modulation removes one of the last practical tells of a social engineering call. This mirrors what our Digital Forensics and Incident Response team is seeing across real incidents: attackers using AI to write ransom notes that are longer, cleaner and more persuasive than the terse demands of a few years ago; using AI to rapidly identify the most sensitive and valuable data on a compromised file share; and using AI to generate more targeted and grammatically flawless phishing at scale. The common thread is that AI is lowering the skill and effort required to execute attacks that previously depended on talent and time.
The defensive lesson sits squarely with process, not technology. Identity verification steps that rely on knowledge an attacker can research or buy, such as a date of birth or an employee number, no longer constitute proof of identity. Service desk and payroll workflows for credential resets and contact-detail changes need verification that cannot be socially engineered, and staff in those roles need to be empowered to slow down and escalate when something feels wrong.
An organisation responsible for the operational technology underpinning a large public facility engaged us to test the physical security of its most sensitive spaces, including plant rooms, communications rooms and the server rooms housing OT infrastructure. Over three days, our consultants conducted reconnaissance in plain clothes, observed staff uniforms and access-card formats, and studied access cards visible in employees' social media photos. They then produced convincing fake access passes and high-visibility clothing and adopted a series of pretexts, posing variously as staff, a telecommunications contractor and, finally, vendor engineers arriving to perform a critical security patch.
The final pretext succeeded completely. A security officer inspected the fabricated access cards, was satisfied, admitted the consultants to the security office and then unlocked a server room and left them alone inside it with the door closed. Within that room our consultants reached live OT and SCADA infrastructure, connected a device to equipment in the rack and obtained network addressing, and observed unattended workstations displaying live CCTV feeds. Tailgating and a slow-closing door had already granted access to restricted executive floors earlier in the engagement, and a service elevator requiring no access card allowed free movement between floors. The engagement was rated Critical.
This case illustrates why operational technology was the standout sector in this year's data, with by far the highest rate of serious findings. OT environments are frequently protected by strong network controls, as they were here, where network access controls twice blocked attempts to connect internally. But physical and human controls are often the weaker link, and physical access to OT is a direct path to impact that bypasses the network entirely. For organisations running critical infrastructure, physical penetration testing and staff security awareness deserve the same rigour as network testing, because an adversary who can walk into the server room does not need to defeat the firewall.
An assessment is only as valuable as the action it drives. Where clients engage us to retest after remediation, we can measure exactly that, and the results reveal one of the clearest signals in this year's data: organisations remediate the findings that matter, and defer the ones that do not.
Closure tracks severity almost perfectly, and inversely. Every Critical finding that was retested had been fixed, and the overwhelming majority of High findings were resolved. From there the resolution rate falls steadily with severity.
| Initial severity | Resolution rate |
|---|---|
| Critical | 100% |
| High | 89% |
| Medium | 57% |
| Low | 22% |
| Informational | 31% |
Resolution rate by initial severity, 2025-26.
Overall, roughly half of all retested findings were fully or partially closed. But the aggregate masks the real story told by the severity split: when a finding poses serious risk, it gets fixed, quickly and almost without exception. The items left open are, with one important exception, largely hardening and configuration matters such as security header hardening, verbose error handling and TLS configuration, which many organisations reasonably choose to schedule or risk-accept rather than treat as emergencies. The exception is incomplete multi-factor authentication, which remains one of the more common unresolved findings and, unlike the rest of that list, is not a cosmetic hardening item. Given how central identity is to the serious findings elsewhere in this report, deferred MFA deserves to be treated as a priority, not a backlog entry.
This is the clearest evidence we have for the argument the Offensive team has made for years: regular penetration testing, followed by disciplined remediation, measurably reduces the serious risk in an environment. The largest retest of the year illustrates the point. A financial institution's mobile application testing produced a substantial set of findings across multiple apps; by retest, every Critical and the large majority of High findings had been remediated, even though lower-severity items remained on the backlog.
One caveat on coverage: retests naturally lag the original assessment by weeks or months, so only a portion of this year's engagements have reached a formal retest so far. This is a timing effect, not a measure of remediation discipline; many more of this year's engagements will likely have retests completed in the period ahead. The remediation pattern above is drawn from the engagements that have completed that cycle and is representative of how our clients respond.
A penetration test is, by nature, a point-in-time assessment. It reflects the state of an environment during the days it was tested. Many organisations commission one once a year, and in a slower-moving world that was often enough. It is increasingly not. Environments now change constantly, and AI has accelerated this further by allowing software to be built and deployed far faster than before. A finding remediated in July says little about code shipped in September. The gap between point-in-time assessments has become one of the most under-appreciated risks in the assurance model.
In response, we have begun delivering continuous penetration testing to a number of clients. Rather than a single engagement followed by a report, testing runs on an ongoing basis and results are delivered in real time through our penetration test reporting portal. Clients see issues as they are identified rather than waiting for a document at the end, and the assurance they gain reflects the current state of their environment rather than a snapshot from months earlier. This is a materially higher level of confidence than an annual test can provide.
Alongside this, the Offensive team has been closely involved in the development and delivery of our breach and attack simulation service, offered through our Security Operations Centre. Built on OpenAEV, this service continuously simulates the tactics, techniques and procedures of real-world threat actors, drawn directly from what our Digital Forensics and Incident Response team observes in live incidents. The two services are complementary. Continuous penetration testing applies the skill and creativity of a security professional to find what automated tooling cannot; continuous breach and attack simulation replicates known adversaries and their techniques at scale, tailored to an organisation's profile, industry vertical and geography.
Both point in the same direction. As the pace of change accelerates, we expect demand to move steadily away from point-in-time results and towards continuous assurance, where organisations can have confidence in their security posture not just on the day a test concluded, but every day after it.