Advertise on podcast: IT Horror Stories with Jack Smith

Two critical PHP vulnerabilities. Emergency patches. Government websites going offline. And IT teams around the world suddenly discovering just how much forgotten infrastructure they're responsible for. But the real horror story isn't PHP itself. It's the years of technical debt, unsupported software, missing documentation, and Shadow IT that turn a security update into a business crisis. Because you can't patch a server you don't know you have. Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/jacks-rant-php-panic-and-technical-debt/ Sources and further reading : https://www.php.net/supported-versions.php https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/ https://www.php.net/supported-versions.php 00:22 Introduction 00:39 PHP Security Flaw 02:00 RCE Dangers 02:35 Patch Release Chaos 05:01 Identifying Vulnerable Systems 06:54 Widespread Impact 09:04 AI in Discovery 09:15 GitLab Joins Chaos 09:32 Addressing Technical Debt 11:22 Possible Exploits 11:58 Emergency Wrap-up 12:48 The Real Horror 14:26 Conclusion

Companies complain that they can't find the right technical people. Technical people complain that companies have no idea who they're actually looking for. This time, Jack crosses to the other side of the table with Ashley Randall to find out why both might be right. We look at how organizations turn operational problems into job descriptions, why they search for impossible unicorns, and what happens when the person they hire has the right skills for a job that doesn't actually exist as advertised. From HR screening and mismatched expectations to KPIs, management workshops, organizational silos, and the eternal question of whether HR is really there for you, we explore what happens when technical specialists and the business speak very different versions of the same language. Sometimes the problem isn't the person you hired. It's the job you thought you were hiring them for. To find out more about Ashley Randall and Aspiring Redirection, visit: Ashley Randall: https://www.linkedin.com/in/ashley-randall7/ Aspiring Redirection: https://www.linkedin.com/company/aspiring-redirection/ Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/episode-27-wrong-person-right-skills/ 00:00 Introduction 00:43 Business Perspective 02:03 Hiring Challenges 04:48 Evaluating Talent 07:02 Structural Issues 08:52 Role Mismatches 13:24 Miscommunication Effects 17:15 Improving Processes 24:00 Culture and Metrics 33:43 HR and Employee Relations 39:23 Conclusion

Jack talks with Harvey Scolnick about his years working with air traffic control technology and the failures that came with it. From construction work accidentally cutting a critical cable and knocking an air traffic control facility offline, with systems unavailable and aircraft still in the sky, to the people on the ground having to fall back on procedures, neighboring facilities, and some very human problem-solving. In addition, we look at the redundancy behind air traffic control, what recovery looks like when safety-critical infrastructure fails, and why even carefully designed systems can still be brought down by something remarkably mundane. Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/episode-26-cleared-for-disaster/ Find out more about Harvey Scolnick : https://www.scolnickatc.com/ 00:00 Introduction 00:55 Harvey's Journey 02:13 Becoming ATC 05:34 Airways and Radar 07:03 Separation Standards 11:21 Busy JFK 14:33 Iconic Aircrafts 21:12 Technology Upgrades 29:27 Preventative Measures 38:10 AI and Future 41:27 Weather Challenges 43:57 Conclusion

Someone asked us why we weren't on MeshCore yet. First we had to establish that it wasn't a new kind of thrash metal. Then we discovered an off-grid messaging network built from little radios, antennas, repeaters, and licence-free spectrum. So we started digging. How does it route messages ? How private is it ? What happens when repeaters disappear ? And haven't we built something suspiciously similar before ? MeshCore turns out to be considerably more interesting than just another messaging app. Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/jacks-rants-meshcore/ MeshCore documentation used : - FAQ : https://docs.meshcore.io/faq/ - Packet Format : https://docs.meshcore.io/packet_format/  - Payloads : https://docs.meshcore.io/payloads/ - Companion Protocol: https://docs.meshcore.io/companion_protocol/ - CLI Commands : https://docs.meshcore.io/cli_commands/ MeshCore Map : https://meshcore.co.uk/map.html 00:00 Introduction 00:46 Discovering Mesh Core 02:09 Radio and Repeaters 05:19 Free Radio Insights 10:35 Encryption and Privacy 14:26 Old Meets New 15:19 Infrastructure Challenges 18:16 Conclusion

IT may run on the same protocols everywhere, but the people operating it certainly don't. Put teams from different countries, companies, and working cultures onto the same project and apparently simple questions about responsibility, communication, deadlines, and escalation can suddenly have very different answers. This episode looks at what happens when those differences become part of the technical problem. From assumptions that nobody realised they were making to communication styles that work perfectly well locally but collide spectacularly across borders, we discuss how international IT teams get themselves into trouble — and what years of working across cultures can teach you about avoiding it. And no, the solution isn't another mandatory cultural-awareness PowerPoint. Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/episode-25-cultural-differences-in-it/ 00:00 Introduction 00:41 Cultural Intricacies 03:12 Sales Challenges 06:02 Engineering Insights 10:32 Crisis Management 14:10 Data Center Differences 16:00 Luxembourg's Unique Edge 17:52 European Culture Wrap-up

Texas, 1978. Robert was working at a cotton co-op running what may have been one of the world's earliest online auction systems. Farmers received punch cards representing their bales of cotton - occasionally complete with enough stray cotton fibres to jam the card readers - while buyers placed bids remotely using leased IBM 3270 terminals and acoustic coupler modems. After an upgrade, the mainframe refused to come back properly. An IPL produced a corrupted device address before dropping the machine into a hard wait. Single-cycling the processor indicated that an UNPK (Unpack) instruction was producing the wrong output from perfectly good input. The instruction itself had effectively broken. And yes, this episode contains a lot of old IBM hardware and mainframe terminology. We know. That's part of the fun. Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/episode-24-when-unpk-broke/ 00:00 Introduction 00:43 Robert's Background 02:14 IBM DOS 03:27 Cotton Auction System 05:37 Online Auction 07:14 SNA Protocol 09:05 Hardware Issue 13:20 Debugging Unpack 17:13 IBM Fix 21:23 Conclusion

A modern pinball machine isn't just flippers, bumpers, lights, and a very large box making expensive noises. It's a connected computer with software updates, online score tracking, player accounts, remote management, and an Internet connection. Evert Brochez from Torius joins Jack to explain how pinball evolved from electromechanical machines into something that looks suspiciously like an IoT device. But once you connect a pinball machine to the Internet, familiar IT questions start appearing. Who maintains the software? How long will it be supported? What can operators manage remotely? How much do we trust the manufacturer with security and access? We look at modern pinball from the operator's perspective, the realities of software quality, and the surprisingly unanswered cybersecurity questions that appear when the arcade machine becomes another device on the network. Find out more about Torius : Website : https://www.horecaspelen.be/ Facebook : https://www.facebook.com/Bingovit Flippers & Bier Podcast (in dutch) : https://open.spotify.com/show/5kvyHkIfo6HfdlulPeDScL More about Comic Sans : Gent : https://cafecomicsans.be/ Brussels : https://www.comicsansbrussels.be/ Facebook : https://www.facebook.com/cafecomicsans Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/episode-23-pinball-as-iot/ 00:00 Introduction 00:34 Pinball Enthusiast 02:20 Pinball Operations 03:54 Maintenance Insights 05:16 IoT Integration 06:53 Player Engagement 09:44 Tech Challenges 13:41 Future Features 21:57 Software Updates 30:19 Conclusion

The Three Envelopes: Blame, Reorganize, Repeat There is an old management joke about an outgoing manager leaving three numbered envelopes for their successor. When the first crisis arrives: blame your predecessor. The second: reorganize. And when the third arrives... prepare three envelopes. We look at why this joke has survived for decades, and why anyone who has worked in corporate IT will recognise far too much of it. From inherited problems and reorganisations to management changes that somehow leave the underlying problems untouched, they explore what the Three Envelopes tells us about blame, accountability, and the wonderfully repetitive nature of IT organisations. Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/episode-22-the-three-envelopes/ 00:00 Introduction 01:01 The Three Envelopes 05:02 Blame Management 10:28 Management Insights 19:10 Entertaining Anecdotes 23:35 Conclusion

Jack's Rants - Why You Need to Reboot : Why Rebooting Your Computer Actually Fixes Problems "Have you tried turning it off and on again ?" became an IT cliché for a reason. Rebooting clears accumulated state, resets resources, and fixes a surprising number of problems. From Unix uptime bragging rights to mainframe IPLs and Windows servers nobody is allowed to restart, every system has its own relationship with rebooting. Maybe what we really need is a reboot SLA. Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/jacks-rants-can-i-keep-your-id/ 00:00 Introduction 02:17 Developer Habits 04:01 Mainframes & Servers 06:18 Reboot Realities 08:19 Conclusion

Testing software sounds simple enough. But what exactly should you test, where should those tests happen, and how do you decide which parts of a complex system need the most attention? Jack talks with Mooly Beeri about software testing from a developer's perspective: identifying the right test points, understanding how different parts of a system interact, and building testing into the development process rather than treating it as something that happens at the end. A practical look at what it actually means to test software properly. You can read more from Mooly at https://www.bettersoftware.dev/ Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/episode-21-testing-software-properly/ 00:00 Introduction 01:05 Mooly's Background 01:43 Automotive Software 04:01 Software Challenges 06:21 Bug Management 12:11 Improving Processes 15:42 Communication Importance 28:07 Summary

One day, a busy IBM-compatible mainframe began slowing to a crawl. Hundreds of programmers noticed immediately—some even resorted to banging on the server room window whenever the system became unusable. The problem appeared after a microcode upgrade, but nothing pointed to an obvious cause. In this episode, Jack Smith talks to Matt about an extraordinary piece of low-level troubleshooting that led deep into the internals of VM, interrupt handling and timer queues. Armed with nothing more than hex dumps, careful reasoning and a willingness to modify live memory, Matt uncovered a vendor bug and devised a temporary workaround that kept the system running until a permanent fix arrived. It's a fascinating story of how understanding a system at its lowest levels can solve problems that no diagnostic tool could explain. Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/episode-20-microcode-mayhem/ 00:00 Introduction 01:07 Mainframe Tech 04:38 Microcode Issues 07:19 Timer Interrupts 15:02 Modern Comparisons 19:44 Final Insights 22:18 Conclusion

Artificial intelligence didn't invent Shadow IT—it made it invisible. In this Jack's Rant, Jack Smith explores how AI tools like ChatGPT, Copilot and Claude have fundamentally changed the way employees solve problems. No servers under desks. No rogue software installations. Just a browser tab and a prompt. From confidential data and AI-generated scripts to fragmented workflows and "ChatGPT says..." becoming the new expert opinion, this episode examines why AI has lowered the barrier to creating business-critical systems outside IT's view. But this isn't a rant against AI. It's a reminder that Shadow IT has always been a symptom, not the disease. Employees don't create workarounds because they enjoy breaking policy—they do it because they're trying to get their jobs done. Instead of asking how to stop people from using AI, perhaps IT should be asking why they felt the need to use it in the first place. Because the organizations that succeed won't be the ones with the strictest AI policy, but the ones that make the secure, supported way the easiest way. Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/jacks-rants-ai-is-the-new-shadow-it/ 00:00 Introduction 01:11 Shadow IT Explained 02:43 Feedback Loops 04:01 Modern Shadow IT 06:24 Trust in AI 08:25 AI Fragmentation 10:08 Leadership Solutions

Every year, the Melbourne Cup pushes Australia's betting infrastructure to its limits. In 1991, a known software bug turned one of the busiest days of the year into an IT disaster. As millions of bets poured in, CPU utilisation unexpectedly collapsed and the betting system ground to a halt at the worst possible moment. Jack Smith is joined by veteran mainframe specialist Neale to revisit the incident, explain why the bug had been accepted for so long, how the team recovered, and what modern IT professionals can learn about technical debt, capacity planning, and the risks of carrying known defects into critical production systems. Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/episode-19-melbourne-cup-meltdown/ 00:00 Introduction 00:53 Mainframe Basics 02:01 Melbourne Cup Explained 05:01 System Failure 09:06 Aftermath & Reflection 17:03 Learning from Errors 21:53 Modern Vs. Past Tech 29:51 Conclusion

Scambaiters like Kitboga, Jim Browning and Pierogi educate millions, waste scammers' time, and undoubtedly prevent people from becoming victims. As a security professional, I genuinely appreciate what they do. But every time I watch one of these videos, I find myself asking the same question: What happened in the missing five minutes? How does a legitimate remote support session suddenly become full control over the scammer's computer? Is it a vulnerability? Poor operational security? Social engineering? Or simply the part of the story that gets left on the cutting room floor? This isn't a criticism of scambaiters. It's an exploration of the unanswered security questions that every IT professional should be asking, and why understanding how something happened can be just as important as enjoying the outcome. Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/jacks-rants-the-missing-five-minutes/ 00:00 Introduction 00:22 Scambaiter Styles 02:01 The IT Dilemma 04:23 Compromised Systems 06:48 The Editing Reality 09:00 Seeking Security Answers 09:59 Closing Thoughts

Smart cities promise better transportation, connected infrastructure, and improved services—but what happens when everything is connected a little too well? In this episode, our guest shares the story of a security assessment in a major metropolitan smart city where network segmentation had been overlooked, creating unexpected paths between public networks and critical infrastructure. One memorable discovery showed that, with nothing more than the correct IP address, it was possible to operate a parking garage barrier from the city's public Wi-Fi while riding a bus on the opposite side of town. Together, we explore why VLANs and network segmentation remain some of the most fundamental principles in cybersecurity, how convenience can quietly undermine security, and why the smartest technology still depends on good architecture. It's a fascinating story that demonstrates how seemingly small design decisions can have city-wide consequences—and why "everything connected" should never mean "everything can talk to everything else." Want even more info ? Read our show notes and related blog post related to this episode : https://blog.ithorrorstories.eu/episode-18-one-network-to-rule-them-all/ 00:00 Introduction 01:58 Smart City Chaos 10:47 Security Camera Mess 25:09 ANPR Issues 36:08 Concluding Thoughts