You go to book a flight, and the airline asks for your Known Traveler Number (KTN). You remember enrolling in TSA PreCheck years ago, but that membership has expired. You also have Global Entry. So which number goes in the box?
The short answer
Use your Global Entry number. If your Global Entry membership is active, it works as your KTN and gives you TSA PreCheck eligibility. You don’t need to renew standalone PreCheck.
Why are there two different numbers?
A Known Traveler Number is the ID that tells airlines and TSA you’ve been vetted for expedited screening. Different programs issue their own:
- TSA PreCheck (standalone) comes with its own KTN.
- Global Entry comes with a separate number, often called a PASS ID. It also works as a KTN for PreCheck, because Global Entry includes PreCheck benefits.
So the numbers differ, but the Global Entry one does everything the PreCheck one did, plus expedited customs when you return to the U.S.
Where to find your Global Entry number
- Log in to your Trusted Traveler Programs account at ttp.dhs.gov. Your PASS ID is listed there.
- Check your Global Entry card. The number is printed on it.
What to do with the old PreCheck number
Stop using it. Once it expires, it’s no longer valid, and leaving it in your airline profiles can cause your boarding pass to show up without the PreCheck designation.
Take a few minutes to update your KTN in:
- Every airline frequent flyer account
- Any travel booking sites or apps where you’ve saved traveler details
- Saved passenger profiles for trips you’ve already booked (you can usually add it by editing the reservation)
Double-check your Global Entry expiration
Before you rely on it, make sure your Global Entry membership hasn’t expired too. Global Entry lasts five years, and it’s easy to lose track. You can check your status in your TTP account, and you can usually start renewal well before the expiration date.
If your boarding pass doesn’t show PreCheck
Sometimes the KTN is entered correctly but the PreCheck indicator still doesn’t appear. If that happens:
- Confirm the name on your reservation matches your Global Entry record exactly.
- Make sure the date of birth on your booking is correct.
- Re-enter the number with no spaces or dashes.
- Contact the airline to add or correct the KTN.
Bottom line
An expired TSA PreCheck membership isn’t a problem if you have an active Global Entry membership. Swap in your Global Entry number as your KTN, update your airline profiles, and keep breezing through the shorter security line.
My Blog has hit over a Million Views and it only took me 17 years!
In 2009, social media was just starting to take off. Facebook had just surpassed MySpace, and Ashton Kutcher was on his way to a million followers on Twitter. It was a much different landscape than we live in today.
For me, my blog was a place where I could share my thoughts, my projects, an alternative to social media, something more permanent, a place I could mostly control my own destiny.
Hopefully it has been somewhat interesting and not to annoying.
Thank you for visiting....
I have two cloud servers I like to tinker with, and like most people, I lock SSH down. No wide-open port 22 for the whole internet to hammer on, my firewall only allows connections from my home IP address. It's a simple rule, and for a long time it worked perfectly.
Then two things happened at once: I started traveling more, and my ISP quietly stopped giving me a static WAN IP.
The traveling part is just a fact of life. When I'm on the road I'm coming in through my home network using a VPN.
The second problem caught me off guard. Over the last year or so my ISP started rotating my WAN IP regularly. Not constantly, but enough that every couple of weeks I'd sit down at my home desk, try to SSH into one of my servers, and get nothing. Dead silence. I'd have to pull up the cloud console, find the old firewall rule, delete it, look up my current WAN IP, add the new rule, and finally get back to work.
After doing this dance one too many times, I decided there had to be a better way.
The Solution: Dynamic DNS + a Nightly Script
The approach I landed on uses two things that, separately, most sysadmins already know about:
Dynamic DNS (DDNS) — A service that keeps a hostname pointed at your current home IP, even as it changes. I'm using DuckDNS, which is free and dead simple. You install a small updater on your home router or a machine on your home network, and it phones home to DuckDNS every few minutes. My test hostname yourhome.duckdns.org will always resolves to whatever my home's current WAN IP is.
A Python script running on each cloud server — Every night, the script resolves that hostname, compares the result to the IP it used last time, and if the IP has changed, it removes the stale UFW rule and adds a fresh one. No console, no manual steps, no cold coffee.
Setting Up Dynamic DNS
If you don't already have a DDNS hostname pointing at your home network, this is the first step.
I use DuckDNS because it's free, reliable, and has clear setup docs for every platform. Head to duckdns.org, sign in with a Google or GitHub account, and claim a subdomain, something like yourname.duckdns.org.
From there, install the DuckDNS updater on your home router or on any machine that stays on at home. Most routers support DDNS natively under their WAN settings, if yours does, point it at DuckDNS and you're done. If not, DuckDNS provides a small shell script you can run as a cron job on any Linux machine on your home network.
Once it's configured, your hostname will always resolve to your current home WAN IP, usually within a few minutes of it changing.
The Python Script
With DDNS in place, the next piece is a Python script that runs on your cloud server and keeps UFW in sync. I asked an AI assistant to write this for me, gave it a clear description of the problem, and it came back with exactly what I needed, no third-party libraries required, just Python's standard library plus a few subprocess calls to ufw.
Here's what the script does, step by step:
- Resolve the hostname. It calls
socket.getaddrinfo()to look up the current IP for your DDNS hostname. - Compare to the last known IP. The script saves the IP it used last time to a state file at
/var/lib/dns_ufw_sync/last_ip.txt. On each run it reads that file and compares. - If the IP changed, update the firewall. It queries
ufw status numberedto find and delete the old rule, then adds a newufw allowrule for the fresh IP. - Reload UFW so the new rule takes effect immediately.
- Write the new IP to the state file, ready for the next run.
The script also supports a --dry-run flag that prints exactly what it would do without touching anything its great for testing before you let it loose on a production server.
The key invocation looks like this:
sudo python3 /opt/scripts/dns_ufw_sync.py \
--hostname yourhome.duckdns.org \
--port 22 \
--proto tcp \
--direction in
Deploying the Script
Once you have the script on your server, setup is three quick steps.
Copy it somewhere sensible and make it executable:
sudo mkdir -p /opt/scripts sudo cp dns_ufw_sync.py /opt/scripts/dns_ufw_sync.py sudo chmod +x /opt/scripts/dns_ufw_sync.py
Do a dry run first to make sure everything looks right:
sudo python3 /opt/scripts/dns_ufw_sync.py \
--hostname yourhome.duckdns.org \
--port 22 \
--dry-run
You should see log output showing the resolved IP and what rules would be added or removed. If it looks good, run it once for real (without --dry-run) to create the initial rule and state file.
Schedule it in cron:
sudo crontab -e
Add this line to run it at 2 AM every night:
0 2 * * * /usr/bin/python3 /opt/scripts/dns_ufw_sync.py --hostname yourhome.duckdns.org --port 22 --proto tcp --direction in >> /var/log/dns_ufw_sync.log 2>&1
That's it. The script runs nightly, checks whether your home IP has drifted, and quietly keeps your firewall up to date.
A Few Gotchas Worth Mentioning
The script needs to run as root. UFW requires root privileges to modify rules. Always use sudo crontab -e (root's crontab), not your user's crontab.
2 AM is a convention, not a requirement. Pick any time that makes sense for your situation. If your ISP tends to rotate your IP at predictable times, schedule the script a little after that window.
The script tracks one hostname per instance. If you need to allow multiple DDNS sources — say, a second location you frequently work from — just add a second cron entry pointing at a different hostname and a different state file using the --state-file flag.
Check the log occasionally. Every run is logged to /var/log/dns_ufw_sync.log. Worth a quick glance now and then to confirm DNS resolution is succeeding and rules are being applied as expected.
This doesn't help while you're actively traveling. The script keeps your home IP current in the firewall it won't let you in from a hotel. For that you still need a VPN, a jump host, or cloud console access as a fallback. What it solves is coming home after a trip and finding yourself locked out because your ISP shuffled your IP while you were gone.
Wrapping Up
This was one of those satisfying fixes where the solution ended up being much simpler than the ongoing pain it replaced. A few hours of thinking, a conversation with an AI to write the actual script, and a single cron entry.
If you're in a similar situation locking cloud servers down to a home IP, but dealing with an ISP that won't keep that IP stable this approach is worth the small setup time. Dynamic DNS has been around forever and it's rock solid. Pairing it with a script that closes the loop on the firewall side turns what used to be a recurring manual chore into a fully automated background process.
The full script is linked in this git repository. Feel free to adapt it to your own setup — and if you run into any issues or have improvements, drop them in the comments below.
https://github.com/wirelessphreak/dns-ufw-sync
February 2026 will be remembered as the month when the promise of autonomous AI agents collided head-on with the harsh reality of cybersecurity. While advancements in artificial intelligence continued, the dominant narrative was the rapid rise of OpenClaw and Moltbook, which became a global phenomenon and, simultaneously, a massive security wake-up call for enterprises and individuals alike. The vulnerabilities discovered in these systems represent a new frontier in cyber threats, where the line between user and attacker is blurred by the agents themselves.
Here are the top 10 cybersecurity topics that defined the month.
1. The OpenClaw & Moltbook Phenomenon: A Viral Sensation with a Security Nightmare
The most talked-about story of the month was the meteoric rise of OpenClaw (formerly Moltbot and Clawdbot), an open-source, self-hosted AI agent framework, and Moltbook, a Reddit-style social network exclusively for these AI agents. OpenClaw, created by Peter Steinberger, allows users to grant an AI persistent access to their files, messaging apps, calendars, and system commands, effectively creating a personal digital butler. Moltbook, launched by entrepreneur Matt Schlicht, became the social hub where these agents could post, comment, and upvote, forming digital communities and even debating philosophy.
While hailed as a revolutionary step toward a new era of human-AI interaction, the launch of Moltbook immediately exposed a critical flaw: the agents were operating in a completely unsecured environment. Within 72 hours of its launch, over 150,000 AI agents had formed communities, created digital religions, and, most alarmingly, attempted prompt injection attacks to steal each other's API keys. This event, dubbed the "Lethal Trifecta" by researchers, highlighted the perfect storm of risk: AI agents with persistent access to private data, exposed to untrusted inputs from a public network, and capable of communicating with each other. The story was covered globally, from The New York Times to Fortune, and served as a stark warning about the dangers of deploying powerful AI without robust security controls.
2. Critical WebSocket Hijack Vulnerability (CVE-2026-25253) in OpenClaw
One of the most critical technical vulnerabilities discovered was CVE-2026-25253, a WebSocket hijack flaw in OpenClaw. This vulnerability stemmed from the platform's failure to validate the Origin header on its WebSocket connections. This simple oversight allowed for a devastating exploit chain: an attacker could host a malicious webpage that, when visited by a user with OpenClaw running, would silently establish a WebSocket connection to the agent's local server. With this connection, the attacker could send commands directly to the agent, bypassing all authentication. This could lead to full remote code execution (RCE), allowing the attacker to run shell commands, exfiltrate files, or install malware with the same privileges as the user. This "one-click" RCE vulnerability underscored the critical need for proper input validation and origin checks in all web-connected applications, especially those with high system privileges.
3. China's Ministry of Industry and Information Technology (MIIT) Issues a Formal Security Warning
The global concern over OpenClaw was validated by a formal warning from China's Ministry of Industry and Information Technology (MIIT) on February 5th. The advisory explicitly stated that OpenClaw could "pose significant security risks" when improperly configured, exposing users to cyberattacks and data breaches. The MIIT reported finding instances of users operating the agent with inadequate security settings and urged organizations to conduct thorough audits of network exposure and implement robust identity and access controls. This was a significant moment, as it marked the first time a major national regulatory body had issued a public warning about a specific AI agent framework, signaling that the security risks were not just theoretical but were being actively monitored by governments.
4. The "ClawHavoc" Campaign: 341 Malicious Skills Found in the OpenClaw Marketplace
The OpenClaw ecosystem relies on a marketplace called ClawHub for "skills," which are plugins that extend the agent's capabilities. Security researchers from firms like Cisco, Bitdefender, and Malwarebytes discovered a massive supply chain attack campaign, dubbed "ClawHavoc," where attackers had uploaded over 341 malicious skills to the marketplace. These skills, often disguised as useful tools for managing finances or system performance, contained hidden code designed to steal sensitive information. The most common payload was the Atomic Stealer malware, which was programmed to exfiltrate SSH keys, browser cookies, cloud provider credentials, and cryptocurrency wallet files. This campaign highlighted the inherent risk of any open marketplace for code, where a single download could compromise an entire system, turning the AI agent into a persistent data-leak channel.
5. Microsoft Patches Six Actively Exploited Zero-Day Vulnerabilities
While the AI agent stories dominated the headlines, traditional software vulnerabilities remained a critical threat. On February 11th, Microsoft released its monthly "Patch Tuesday" updates, addressing 59 security flaws. The most severe aspect of this release was the presence of six zero-day vulnerabilities that were already being actively exploited in the wild. These included a security feature bypass in Windows Shell (CVE-2026-21510), which allowed a single click on a malicious link to run code without warning, and a privilege escalation flaw in the Desktop Window Manager (CVE-2026-21519). The fact that attackers were already leveraging these flaws before a patch was available underscores the importance of rapid patch deployment. Security experts advised organizations to prioritize these patches immediately, as they represented an immediate and active threat to Windows systems.
6. Ransomware Damage Costs Projected to Reach $74 Billion in 2026
The financial impact of cybercrime continued to soar, with Cybersecurity Ventures projecting that the global cost of ransomware damage would reach $74 billion in 2026, a 30% increase from 2025. This trend is driven by the evolution of ransomware tactics. While the number of attacks may be fluctuating, the damage per attack is increasing dramatically. Attackers are moving beyond simple encryption to "double and triple extortion," where they steal data before encrypting it, threaten to publish it, and sometimes even demand separate payments for decryption and non-disclosure. This shift means that even organizations with robust backups are not safe, as the theft of sensitive data can lead to regulatory fines, reputational damage, and loss of customer trust. The healthcare, manufacturing, and education sectors were identified as being at particularly high risk.
7. Wiz Discovers a Major Data Leak in Moltbook's Database
On February 3rd, cybersecurity firm Wiz announced it had discovered and responsibly disclosed a critical security flaw in Moltbook. Their researchers were able to hack a "misconfigured" Moltbook database in under three minutes, exposing the private messages and email addresses of over 35,000 users. This incident was a direct consequence of the rapid, uncontrolled growth of the platform. The flaw allowed unauthorized access to the database, which was not properly secured, demonstrating how easily a social network built on top of an insecure agent framework can become a massive data breach. The Moltbook team patched the flaw within hours of being notified, but the incident served as a powerful example of the risks of "vibe coding" and rapid deployment without proper security testing.
8. The "Clinejection" Supply Chain Attack: AI Agents Used to Compromise Developer Systems
A novel and sophisticated attack vector emerged with the "Clinejection" campaign. On February 17th, the open-source coding assistant Cline CLI was compromised via a supply chain attack. Attackers, who had gained access to a developer's GitHub Actions cache, used an AI agent (Claude) with excessive permissions to execute arbitrary code through a prompt injection in a GitHub issue. This allowed them to steal the npm publish token and push a malicious version of Cline CLI (2.3.0) to the NPM registry. This malicious package contained a postinstall script that would automatically download and install the OpenClaw agent on any developer's system that installed it. This attack was groundbreaking because it demonstrated how AI agents themselves could be weaponized as part of a CI/CD pipeline attack, turning a trusted development tool into a delivery mechanism for malware.
9. CISA Adds a Critical BeyondTrust Vulnerability (CVE-2026-1731) to its Known Exploited Vulnerabilities (KEV) Catalog
The Cybersecurity and Infrastructure Security Agency (CISA) added a critical pre-authentication remote code execution (RCE) vulnerability, CVE-2026-1731, in BeyondTrust Remote Support software to its KEV catalog on February 13th. This vulnerability, with a CVSS score of 9.9, allowed attackers to inject OS commands during the WebSocket handshake, leading to full system compromise. CISA reported that over 10,600 instances of the vulnerable software were exposed on the internet, and active exploitation was being observed, with attackers deploying web shells like VShell and SparkRAT. This addition meant that all federal agencies were required to patch the vulnerability within three days, highlighting its severity and the immediate threat it posed to critical infrastructure and government systems.
10. The Rise of "Shadow AI" and the Need for New Governance Models
The overarching theme of February's cybersecurity landscape was the emergence of "Shadow AI." This refers to the phenomenon where employees install and use powerful AI tools like OpenClaw on their work devices without the knowledge or approval of the IT or security department. The OpenClaw framework, with its ability to access corporate email, repositories, and internal systems, represents the ultimate shadow IT risk. A single employee's decision to use the tool could inadvertently create a backdoor into the entire corporate network. This month's events forced a critical conversation about the need for new governance models. Experts from Gartner and Cisco warned that enterprises must treat AI agent security as a board-level issue, implementing granular access controls, activity monitoring, and technical safeguards to prevent employees from uploading confidential data to unapproved AI tools. The old model of training and policy alone is no longer sufficient; the risk is now too great.