The Diminishing Returns of Stacking DMZ Layers

Thesis. Adding more DMZ layers, more zones, more firewalls, and more inspection hops produces diminishing security returns and rising operational costs. Past a certain point, each additional firewall blocks fewer attacks and more legitimate work. The architectural goal should be layered controls, not layered subnets. The harder discipline is recognizing when a zone no longer earns its cost and having the judgment to remove it.

---

Executive Summary

A DMZ is a network segment placed between an external and an internal firewall. It is also one of the most reliable patterns in enterprise security history. NIST has formalized it since the early 2000s, most major regulators expect to see something like it, and for a clear class of workloads the pattern still earns its cost.

The question this article asks is not whether the DMZ pattern is valid. It is whether stacking more of them is still the right answer when an environment grows, modernizes, or moves to cloud. The evidence from the last decade points in the same direction: Verizon’s Data Breach Investigations Report, NIST’s reframing of trust boundaries in SP 800-207, and Google’s published move beyond the corporate perimeter with BeyondCorp all suggest that the marginal security benefit of additional DMZ layers flattens quickly. The marginal operational cost keeps climbing.

The danger is not having one firewall too many. The danger is ending up with a topology nobody can explain without opening four diagrams, calling three teams, and discovering production took a different path six months ago.

This piece argues a sharper position than is usual in cloud-versus-on-prem debates:

• Layered controls, such as edge protection, segmentation, identity, workload policy, and observability, remain foundational.
• Layered subnets enforced by appliance firewalls are one implementation of those controls. Adding more of them stops being free, then stops being neutral, then becomes net-negative.
• The right architectural question is no longer “where does the DMZ go?” but “where do trust boundaries, inspection points, and policy enforcement actually need to live for this workload?”

What follows: what a layered DMZ really is, why it became the default, the diminishing-returns argument with sources, the over-layered anti-pattern (with diagram), where the pattern still earns its cost, what modern controls do better now, five reference architectures with diagrams, a decision matrix, three case notes from public breaches, and a practical checklist for architects. Source notes at the end.

---

What “Layered DMZ” Actually Means

In its strict sense a DMZ (“demilitarized zone”) is a network segment between an organization’s internal network and an untrusted network – usually the internet – with stateful firewalls on both sides. NIST SP 800-41 Rev. 1 (Scarfone & Hoffman, 2009) defines this pattern explicitly and recommends it as a baseline for organizations exposing services to the internet ³.

A layered DMZ extends the pattern by introducing additional zones, typically called Outer DMZ, Inner DMZ (or “back DMZ”), and Internal / Intranet, separated by additional firewalls. The most widely deployed enterprise variant is four zones:

• Internet Untrusted. External users, partners, attackers, bots.
• Outer DMZ Internet-facing services: WAFs, reverse proxies, public web servers, edge load balancers, public API front-ends. The only zone allowed to receive inbound internet traffic.
• Inner DMZ Application and integration services: app servers, internal APIs, integration brokers, message queues. Reachable from the Outer DMZ on a small, explicit set of ports; never directly from the internet.
• Internal / Intranet Data tier, identity, internal applications, corporate network. Reachable only from the Inner DMZ on tightly scoped paths.

Some organizations stop at one DMZ (the original “between two firewalls” pattern). Others extend to three, four, or more – adding zones for management, partner integrations, services, data gateways, and compliance boundaries. Defense and government environments often layer further to match classification trust labels.

The principle behind every variant is the same: place stateful inspection between every meaningful trust boundary and force north-south traffic to traverse it.

Some organizations stop at one DMZ; others extend it further. The Outer/Inner split is the most common enterprise pattern and the one this article uses as the reference baseline.

---

Why It Became the Industry Default

Three forces made layered DMZs the default enterprise pattern for nearly two decades.

1. The threat model fit. Through the early 2000s, the predominant external threat was network-borne: scans, worms, exploit attempts, brute force against exposed ports. NIST SP 800-41 codified zone-based firewalling as a proven mitigation, and most enterprise architectures of that era – bank cores, retail, telco, utilities – already had a clear north-south traffic axis to defend ³.

2. Regulation made it inspectable. PCI-DSS, HIPAA, NERC CIP, and various national banking and telecom regimes have long expected some form of network segmentation between sensitive data and the rest of the network. PCI DSS v4.0 (PCI SSC, March 2022) continues to treat network segmentation as a primary scope-reduction strategy ⁷. A two- or three-zone DMZ is a clean way to evidence that to an auditor – two firewalls, two rule sets, two change windows.

3. The operating model already existed. On-prem networks had owners: a network team, a perimeter security team, a firewall team. The layered DMZ mapped neatly onto that ownership structure. Adding more zones felt like adding more rigor. In the on-prem world, with stable topologies and slow change cadences, it often was.

For workloads matching all three conditions – predominantly network-borne threats, regulator expectations, stable on-prem topology, a dedicated network team – the layered DMZ remains a reasonable default. The argument of this article is not against the pattern. It is against treating “more layers” as a synonym for “more security” when one or more of those conditions no longer holds.

---

The Math of Diminishing Returns

If a single DMZ raises the cost of compromise from X to X + \delta_1, and a second layer raises it to X + \delta_1 + \delta_2, the architectural question is whether \delta_2 is large enough to justify the friction it introduces, and whether it is large for the threats that actually matter.

Three lines of evidence suggest \delta_2, \delta_3, and successive layers shrink quickly.

1. The empirical attack vectors do not pass through the third firewall

The Verizon 2026 Data Breach Investigations Report finds that 31% of breaches now start with the exploitation of software vulnerabilities – surpassing stolen credentials as the top initial-access vector – and 48% involve ransomware ¹. Across prior reports, web-application attacks, supply-chain compromise, and credential abuse have consistently dominated the initial-access categories. Few of these paths benefit from the third or fourth firewall in a layered DMZ:

• SQL injection through an exposed web tier does not care how many firewalls sit behind it; the injection succeeds at the application layer, not at the network layer.
• A compromised vendor library has no concept of subnet boundaries; it ships with the application into whatever zone the application runs in.
• A valid credential used by an attacker traverses the firewall stack exactly as the legitimate user does – because, to the firewall, it is the legitimate user.

A two-zone DMZ that filters obvious junk and exposes only the necessary services already addresses most of the network-layer attacker. A third or fourth zone primarily filters traffic from internal sources that the attacker has, by hypothesis, already reached.

2. Identity has displaced location as the meaningful trust boundary

NIST SP 800-207, Zero Trust Architecture (Rose, Borchert, Mitchell, Connelly, August 2020), reframed enterprise security around an explicit assumption: “no implicit trust is granted to assets or user accounts based solely on their physical or network location” ². The publication is not anti-firewall. It is anti-“network position equals trust.”

Google’s BeyondCorp paper (Ward & Beyer, ;login:, December 2014) stated the same thing six years earlier and from inside a hyperscaler:

“Virtually every company today uses firewalls to enforce perimeter security. However, this security model is problematic because, when that perimeter is breached, an attacker has relatively easy access to a company’s privileged intranet. As companies adopt mobile and cloud technologies, the perimeter is becoming increasingly difficult to enforce.” ⁵

Two consequences follow for layered DMZ design. First, a workload that authenticates every request against a real identity (workload identity, OIDC, mTLS) does not need an additional network zone to do the same job less precisely. Second, an attacker holding a valid credential is not slowed by the fourth firewall any more than by the first.

3. Complexity itself enlarges the attack surface

Bruce Schneier’s repeated formulation – “complexity is the worst enemy of security” – has been borne out across two decades of incident data ⁸. NIST SP 800-160 Vol. 2 Rev. 1 (Ross et al., December 2021) names complexity reduction as a foundational cyber-resiliency objective on the grounds that systems too complex to reason about are systems too complex to defend ⁴.

Each additional DMZ layer introduces:

• another firewall ruleset, with its own drift over time,
• another change-management surface and team interface,
• another scaling and capacity-planning concern,
• another potential failure domain in the critical path of every request.

The simultaneous claim that “this additional layer further reduces breach probability” and that “this additional layer adds rule-change latency, throughput cost, and operational toil” is testable. The first is rarely measured. The second is felt every release.

What the data does not show

It is difficult to find empirical evidence that organizations operating four or five layered DMZ zones experience materially lower breach rates than peers running two well-managed zones, controlling for sector and maturity. What the breach data does show is that attackers typically exploit a single weak link – exposed service, valid credential, vulnerable component, supply-chain insertion – rather than systematically defeating successive network controls. Stacking more network controls beyond a point does not address the dominant failure modes; it only addresses harder versions of failure modes that the second layer already mostly addressed.

---

The Over-Layered DMZ Anti-Pattern

A specific failure mode shows up repeatedly in mature enterprises that have been adding zones over many years without removing any:

The symptoms are recognizable:

• Latency stacking Every additional inspection hop adds milliseconds and, more importantly, another failure mode. Latency budgets that mattered for synchronous APIs disappear before they reach the workload.
• Change-control combinatorics A new application path requires firewall rules in five places, owned by three teams, each with a different change window. Lead time to ship a network change is measured in weeks; the delivery team’s lead time is measured in days. The mismatch is where shadow infrastructure begins.
• Shadow paths Under delivery pressure, teams find ways around the official path: a “temporary” tunnel from a developer VM, a service exception that becomes permanent, a partner integration that bypasses three of the four firewalls. Once a shadow path exists, the official topology no longer describes the real attack surface.
• False audit comfort The diagram looks rigorous in a control review. The actual production traffic graph – visible in flow logs if anyone looks – does not match the diagram.
• Diminishing operator visibility The more devices in the path, the harder it is to reconstruct what happened when something breaks or is exploited. Forensics across five inspection points and three teams is meaningfully harder than across two.
• Concentration risk in shared appliances When all paths traverse the same NVA or hub firewall pair, that pair becomes a single point of failure for the entire estate. Inspection capacity becomes a delivery constraint at peak.

None of these failure modes are hypothetical. They are the consistent reason mature enterprises eventually consolidate – moving from “many DMZs” to “fewer, better-controlled” zones with stronger identity and workload-level policy carrying the additional weight.

The honest read is uncomfortable: many over-layered DMZ estates were defensible when each layer was added, but stopped being defensible in aggregate. No single decision was wrong; what was missing was the habit of periodically asking whether earlier decisions still earned their cost.

---

Where Layered DMZs Still Earn Their Cost

The diminishing-returns argument is not an argument against any layered DMZ. There are environments where the original assumptions still hold and the pattern remains the most defensible choice:

• Highly regulated workloads Auditors expect explicit, inspectable network boundaries – typical of some interpretations of PCI-DSS Req. 1, HIPAA Security Rule, NERC CIP-005, FedRAMP High, and certain national banking regimes.
• Legacy applications The application assumes a flat, trusted internal network and cannot tolerate identity-aware proxies, mTLS, or per-workload policy without invasive change.
• Hybrid and mainframe integrations The system of record cannot move and must be reached through a controlled, inspected on-prem path.
• Fixed inspection requirements TLS inspection mandated by policy, DLP at the perimeter, egress filtering tied to threat-intel feeds, classified-data flow controls.
• Centralized network and security operating models A dedicated team owns the wires and can run them at the cadence the business ships software.
• Strict, demonstrable isolation Classified processing, defense multi-level secure environments, or tenant-isolated platforms where subnet-level separation is contractually required.
• Transitional architectures during cloud migration A hub-and-spoke DMZ in the cloud temporarily mirrors the on-prem pattern long enough to migrate workloads without rewriting their security model.

In these cases, “layered DMZ” is not nostalgia. It is the cheapest defensible way to meet a real constraint.

---

Where They Have Become Pure Tax

The same pattern misfires when the assumptions no longer hold:

• Cloud-native applications Apps built around managed services; forcing all traffic through a central inspection point breaks the service model or removes provider-native protections.
• Microservices and Kubernetes platforms East-west traffic dominates and identity-aware policy at the workload is more expressive than subnet rules.
• Serverless workloads Workloads have no durable network position to defend; governance happens through IAM and event-source policy.
• Managed PaaS and data platforms Private endpoints handle reachability; the meaningful control surface is identity and resource policy, not a DMZ subnet.
• Globally distributed front-ends The right place to absorb attack traffic is the provider edge (CDN/WAF/anti-DDoS), not a regional firewall pair.
• High-cadence delivery environments Firewall change tickets become the bottleneck, and shadow ingress paths quietly appear to route around them.
• Forced central inspection Latency, hairpins, single points of failure, or licensing costs grow out of proportion to the residual risk removed.

The failure mode here is not insecurity. It is paying for inspection the workload no longer earns back – a pattern that looks rigorous on a diagram but no longer maps to where the real attack surface lives.

---

What Modern Controls Actually Replace

The case for fewer DMZ layers depends on having something to put in their place. Several categories of control have matured enough to carry load that used to fall entirely on perimeter firewalls and DMZ subnets:

• Edge protection at scale CDN + WAF + anti-DDoS at provider edges (Akamai, Cloudflare, Fastly, AWS WAF, Azure Front Door, Google Cloud Armor, Imperva, and others) absorb most volumetric and OWASP-style attacks far from the origin, with global capacity that on-prem appliances cannot match economically.
• Cloud-native load balancers and API gateways AWS ALB/NLB, Azure Application Gateway and Front Door, Google Cloud Load Balancing – managed L4/L7 entry points with native TLS, identity, and WAF integration.
• Private connectivity to managed services AWS PrivateLink, Azure Private Endpoint, GCP Private Service Connect, and VPC Service Controls remove managed services from the public internet without forcing them through a DMZ subnet.
• Microsegmentation primitives Security groups, NSGs, NACLs, and route tables provide per-workload network policy without dedicated appliances. CSPM/CNAPP/CWPP tooling extends that visibility to workload behavior.
• Cloud-native firewalls and NVAs AWS Network Firewall, Azure Firewall, GCP Cloud NGFW, and third-party NVAs in hub VPCs/VNets – used selectively rather than universally.
• Kubernetes-level policy Ingress controllers, Gateway API, NetworkPolicy, and admission controllers enforce north-south and east-west rules close to the workload.
• Service mesh Mutual TLS, identity-bound authorization, and L7 policy between services – independent of network position.
• Zero Trust and identity-aware access Per-request, per-identity access decisions for internal applications, formalized for U.S. federal agencies in NIST SP 800-207 ² and given a graded adoption path in CISA’s Zero Trust Maturity Model v2.0 (April 2023) ⁶.
• Cloud-native detection and response CSPM, CNAPP, CWPP, flow logs, audit logs, and managed SIEM pipelines provide visibility the classic DMZ did not provide on its own.

None of these eliminate network controls. They redistribute them – pushing some to the edge, some to the workload, and some to identity – so that no single chokepoint has to carry the full weight, and no zone has to multiply just because something needs more protection.

---

Reference Architectures

Five reference shapes that cover most of the territory. None is universally correct; each is a reasonable answer to a different question.

Scenario 1 – Canonical Layered DMZ

The reference case the rest of the article compares against. Internet → Outer DMZ → Inner DMZ → Internal, with three firewalls and a stable mapping between application components and network zones. Defensible when the conditions that made the pattern dominant – regulator expectations, on-prem topology, dedicated network team – still hold. See the diagram in What “Layered DMZ” Actually Means above.

Scenario 2 – The Over-Layered Anti-Pattern

The shape that produces the most over-layered DMZ failures: five or six zones with five firewalls, accreted over years, owned by multiple teams, with no zone ever removed. Often defensible at the moment each layer was added; rarely defensible in aggregate. See the diagram in The Over-Layered DMZ Anti-Pattern above.

Scenario 3 – Cloud-Native Edge Pattern

A public web or API workload running on managed services, with the edge, load balancing, and managed data plane provided by the cloud platform.

Trust is enforced at the edge (WAF, bot, anti-DDoS), at the load balancer (authentication, routing, TLS), at the workload (authorization, input validation), and at managed services (private endpoints, resource policy, IAM). Network position is one signal among several, not the primary one. There is no traditional DMZ in this picture, and the controls it would have provided are present – redistributed.

Scenario 4 – Hybrid Enterprise (Hub-and-Spoke with Inspection)

A regulated enterprise running cloud workloads that must talk back to on-prem systems of record, with central inspection for compliance.

Here the layered DMZ pattern is reproduced – deliberately – in cloud primitives. Inspection lives in a hub, spokes are application zones, and on-prem integration uses the existing private circuits. This is often the right transitional shape and a defensible long-term shape for regulated estates. The cost is real: bandwidth through inspection, NVA scaling, single-pair concentration risk, and operational ownership of the hub. The discipline is the same as on-prem: add hub zones only when they prevent a specific compromise that existing zones do not.

Scenario 5 – Kubernetes-Oriented Pattern

A platform team running multi-tenant Kubernetes with managed data services behind it.

The classic web/app/data subnet separation is not what protects this workload. The meaningful controls are the WAF and load balancer at the edge, the ingress and NetworkPolicy boundary at the cluster, mTLS and authorization in the mesh, workload identity to managed services, and runtime observability. Trying to additionally route every pod-to-pod call through a central firewall usually buys little and costs a lot.

---

Decision Matrix

A qualitative comparison. Ratings are deliberately coarse – Low / Medium / High – because the exact answer depends on workload, regulator, and operating model. The matrix treats the over-layered anti-pattern as its own row so the cost is visible.

Two patterns stand out:

• The over-layered DMZ is the only row where added security strength is on paper only. It costs more on every other dimension without measurably reducing breach probability beyond the canonical two- or three-zone form.
• Zero Trust is usually a complement to one of the others, not a replacement for them. It changes how access is decided, not where workloads run.

---

Case Notes – Three Public Examples

These are not gotcha stories. They are reminders that the dominant failure modes in modern enterprise security are rarely the ones a deeper DMZ stack addresses.

Capital One (2019)

A misconfigured WAF allowed a server-side request forgery (SSRF) against EC2 instance metadata, exposing credentials for an over-privileged IAM role; the attacker exfiltrated approximately 100 million records from S3 ⁹. Capital One ran multiple network zones and inspection layers. The compromise rode IAM and an exposed application, not a missing firewall.

Net lesson: identity scoping and resource policy were the binding constraints. Another DMZ zone would not have changed the outcome.

SolarWinds Orion (2020)

A supply-chain compromise of a privileged IT-management product reached thousands of organizations – including ones with mature layered DMZs – because the malicious payload arrived through a trusted update channel and ran with the privileges of a trusted insider component ¹⁰.

Net lesson: a layered DMZ does not constrain a trusted component already inside it. Software supply-chain validation, egress control, and behavioral detection would.

MOVEit Transfer (2023)

A SQL injection vulnerability in an internet-exposed managed file-transfer product (CVE-2023-34362) was mass-exploited by the Cl0p ransomware group, affecting thousands of organizations ¹¹. Most victims had a DMZ. The vulnerable component was, correctly, in it.

Net lesson: the depth of the DMZ stack is unrelated to the vulnerability of internet-exposed software. Exposed-service inventory, patch cadence, and WAF tuning matter more than zone count.

Each case has many contributing factors. The point is not that DMZs caused these breaches – they did not – but that adding more DMZ layers would not have prevented them. The investments that would have were elsewhere: scoped IAM, supply-chain validation, exposed-service inventory, patch cadence, behavioral detection.

---

Practical Guidance for Architects

A checklist for choosing DMZ depth on purpose:

1. Start from the workload, not the network diagram What does this thing expose, to whom, over what protocol, with what data?
2. Name the threat model out loud Drive-by attacker, credential abuse, supply chain, insider, lateral movement, exfiltration – they are not all addressed by the same control.
3. Separate “layered controls” from “layered subnets.” Decide which controls are required; choose the cheapest implementation that delivers them.
4. Give identity the weight it can carry Workload identity, IAM, and mTLS often do more than another firewall hop, and they survive ephemerality.
5. Use the provider edge for what it is good at CDN/WAF/anti-DDoS at the edge is usually cheaper, faster, and more current than a self-managed equivalent at the origin.
6. Reserve central inspection for traffic that genuinely needs it Egress filtering, TLS inspection mandated by policy, regulated north-south paths – those justify a hub. East-west pod-to-pod chatter usually does not.
7. Make compliance an input, not an excuse Ask the auditor what evidence they expect, not whether a specific topology is acceptable. The set of acceptable topologies is usually wider than it looks.
8. Match the pattern to the operating model A DMZ-style pattern needs a team that can run firewalls at the cadence the business ships software. If that team does not exist, the pattern will be bypassed in practice.
9. Design for blast radius, not just perimeter Assume a layer will fail. What does the next layer actually prevent?
10. Write the rollback Any pattern that cannot be partially reversed when it breaks production is too rigid for a cloud operating cadence.
11. Audit the topology against the actual traffic graph Use flow logs. If the live graph does not match the diagram, the diagram is the wrong source of truth.
12. Remove zones, not just add them Every new zone implies a periodic review of whether existing zones still earn their cost. Most “over-layered” estates got that way by never removing.

Questions to Ask Before Adding Another DMZ Zone

• What specific threat does this zone reduce that the existing zones do not?
• Can identity, workload policy, or edge controls deliver the same reduction more cheaply?
• Who owns the new zone, in operations and in change management? Is that team funded?
• What is the latency, throughput, and dollar cost of the new inspection hop at peak load?
• How will the next architect, in two years, know what this zone is for?
• If the new zone disappeared tomorrow, what compromise becomes plausible that was not plausible yesterday? If the answer is “none I can name precisely,” the zone is buying audit comfort, not security.

---

Final Answer – Is a Layered DMZ Still Relevant?

Yes, narrowly. As a security design principle, layered controls remain foundational. As an implementation pattern, a canonical two- or three-zone DMZ – internet, outer DMZ, internal, with stateful firewalls between – still has clear value for many on-prem and hybrid workloads, and for regulated environments where the audit story is part of the architecture.

As a deeply stacked implementation pattern, it is worth less than is usually claimed. Going from two zones to four or more does not reliably lower breach probability for the threats that dominate today’s data; it reliably raises operational cost, lead time, and complexity. Past a certain point, more layers buy diagram comfort, not security.

The honest framing for architects is this: stop asking where the DMZ goes and start asking where trust boundaries, inspection points, and policy enforcement actually need to live for this workload, this threat model, this regulator, and this operating model. Sometimes the answer is still a layered DMZ. Sometimes it is a different shape that delivers the same controls more cheaply. Maturity means choosing deliberately and removing what no longer defends anything.

Architect’s Takeaway

• The layered DMZ is a pattern, not a law. Keep the principle; choose depth with judgment.
• Layered controls – edge, network, identity, workload, data, observability – are the durable idea. Layered subnets are one way to land them.
• Each new zone after the second buys less security than the previous one and costs more than the previous one. Measure both sides.
• BeyondCorp-style identity, microsegmentation, mTLS, and managed edge controls do not replace security thinking. They are new places to put it.
• If you cannot name the specific compromise a new zone prevents, you do not yet need the new zone.

---

Source Notes

• Verizon, 2026 Data Breach Investigations Report. Verizon Business, 2026. verizon.com/business/resources/reports/dbir. ¹
• NIST SP 800-207, Zero Trust Architecture. Rose, S., Borchert, O., Mitchell, S., Connelly, S. National Institute of Standards and Technology, August 2020. doi.org/10.6028/NIST.SP.800-207. ²
• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy. Scarfone, K., Hoffman, P. National Institute of Standards and Technology, September 2009. doi.org/10.6028/NIST.SP.800-41r1. ³
• NIST SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. Ross, R., et al. National Institute of Standards and Technology, December 2021. ⁴
• Ward, R., Beyer, B. “BeyondCorp: A New Approach to Enterprise Security.” ;login:, Vol. 39, No. 6 (December 2014), pp. 6–11. research.google/pubs/beyondcorp-a-new-approach-to-enterprise-security. ⁵
• CISA, Zero Trust Maturity Model v2.0. Cybersecurity and Infrastructure Security Agency, April 2023. ⁶
• PCI Security Standards Council, PCI DSS v4.0. PCI SSC, March 2022. ⁷
• Schneier, B. “A Plea for Simplicity.” Crypto-Gram, November 1999; restated and expanded in Secrets and Lies (Wiley, 2000) and subsequent essays. The frequently-quoted form is “complexity is the worst enemy of security.” ⁸
• United States v. Paige A. Thompson (W.D. Wash., 2019). Capital One indictment, with subsequent industry post-mortems and the Office of the Comptroller of the Currency enforcement action (Aug 2020). ⁹
• CISA Alert AA20-352A, Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations. Cybersecurity and Infrastructure Security Agency, December 2020 (SolarWinds Orion supply-chain compromise). ¹⁰
• CISA and Progress Software advisories on CVE-2023-34362, MOVEit Transfer SQL injection vulnerability. June 2023. ¹¹