A client emailed me today about an unusual problem. The “Create an Account” link on their website was not pointing to a page of their site, but instead to an IP address. An IP address that, when I ran a whois on it, turned out to be owned by China Telecom.

That was disconcerting. I’m not passing any judgment on anyone in particular in any country in particular, but the fact is, a hugely disproportionate number of online attacks against U.S. sites come from a small number of foreign countries, China being one of them. So, I was alarmed.

My first guess, since I’ve seen WordPress sites get hacked… a few times (much less often since I started using Wordfence as standard practice on every site I build), was that hackers had somehow hijacked this link and were trying to route my client’s users over to their systems in some kind of spoofing/phishing/whatever attack.

Only, the link didn’t actually do anything. There’s no web server listening on that IP address. Hmm.

Next up I looked at the HTML source, since I wasn’t quite sure if the code in question was being generated by their theme (which I built) or by a plugin like WooCommerce, so I wanted to see the CSS classes on the wrapper. Sure enough, it was in code I had built.

When in doubt, always blame your own code first.

But the fact that it was my code wasn’t what really caught my attention. It was the fact that the URL in the HTML wasn’t the IP address at all. It was just a string of 8 digits.

Suddenly it was clear to me that this was not a hack attempt, and China Telecom (or anyone using its services) had precisely zero to do with whatever was going on. This was a peculiar code problem, and it was at least indirectly my fault.

That 8-digit number… it looked very familiar. I knew that, due to some of the peculiarities of this client’s site, the ID values in their wp_posts table are on that order of magnitude. Bingo. This wasn’t a URL at all. It was a WordPress post ID, being incorrectly inserted here because Advanced Custom Fields was outputting the raw ID value instead of using it to look up the corresponding post URL.

Why was that happening? Well, that was ultimately my fault too, having to do with some logic that was designed to tell ACF where to load my custom field groups. When the site was built, I had that code running (technically) too early, then ACF released an update that started throwing up admin notices if you did that, so I rewrote it to run later… only I didn’t realize that my change was causing my code to get applied to a hook after it had already run, so… it wasn’t working. It was a very isolated set of circumstances, so it went unnoticed for months. As far as I know, the only user-facing issue it created was this weird integer URL on the “Create an Account” link on a page few people ever visit.

The simplest explanation is the most likely.

Even if the details are anything but simple. Was someone in China trying to hack my client’s site to phish for their customers’ data, or did I just write some flawed code? Hmm.