1.11.1. Review In the beginner tutorial, we mentioned that every reference in Rust has a lifetime. A lifetime is the scope in which the reference remains valid, and in most cases it is implicit and inferred by the compiler. When you take a reference to a variable, the lifetime begins. When the variable is moved or goes out of scope, the lifetime ends. In other words, for a reference, a lifetime is the name of the code region in which it must remain valid. Lifetimes usually overlap with scopes, but not always. 1.11.2. Borrow Checker Whenever a reference with some lifetime 'a is used, the borrow checker checks whether 'a is still alive. The process is: Trace the path back to where 'a began — that is, where the reference was obtained From there, check whether there are conflicts along that path Ensure that the reference points to a value that can be accessed safely This example uses the rand crate. Add the following dependency to Cargo.toml : [dependencies] rand = "0.8" Consider this example: use rand :: random ; fn main () { let mut x = Box :: new ( 42 ); let r = & x ; if random :: < f32 > () > 0.5 { * x = 84 ; } else { println! ( "{}" , r ); } } x is of type Box<i32> Declaring r as a reference to x means the reference’s lifetime begins on that line (line 5) On line 7, the value of x is modified through dereferencing. That requires a mutable reference to x . At this point, the borrow checker looks for a mutable reference to x and checks whether its use conflicts with anything else. In this example there is no conflict, so the code is valid You may ask: line 7 is inside the scope of r . Since *x needs a mutable reference to x , shouldn’t having both the immutable reference r and the mutable reference *x in the same scope violate the borrowing rules and produce an error? In fact, Rust is smart enough to know that if the if branch is taken, the else branch cannot be taken. r is never used in the if branch at all, so using the mutable reference *x in the if branch is fine

Dysphoria: A 200k-Device Botnet Using Blockchain Name Resolution and Infected Device Relays 1. Basic Information Article Title : New Dysphoria DDoS botnet spreads to 200k devices worldwide Publisher : BleepingComputer Publication Date : 2026-07-27 Original Source : https://www.bleepingcomputer.com/news/security/new-dysphoria-ddos-botnet-spreads-to-200k-devices-worldwide/ Primary Source : https://blog.xlab.qianxin.com/dysphoria/ Related Entities : Dysphoria, jackskid, fbot, ENS, SNS, UPnP, Telnet, SSH, IoT/embedded Linux Related CVEs : CVE-2013-3307, CVE-2016-20016, CVE-2017-17215, CVE-2017-5259, CVE-2018-14558, CVE-2020-25499, CVE-2020-8515, CVE-2022-35733, CVE-2025-9528, CVE-2025-28137, CVE-2025-34152, CVE-2025-55182, and others Severity : High Main IOCs : burrberry.eth , ukranianhorseriding.eth , 24carnforth2merseyside.sol , login.trees4sale.net , c2.saintpetersburgresident.ru 2. Summary This is a large-scale Linux botnet. It breaks into devices using weak Telnet/SSH passwords and various IoT RCE vulnerabilities. It gets multi-stage C2 servers from ENS/SNS records. It turns infected devices into relay nodes or DDoS bots by opening 155 ports using UPnP. 3. Attack Flow Infection and DDoS Chain Attackers compromise routers, gateways, and cameras using weak Telnet/SSH credentials or known RCE vulnerabilities. The malware runs a Linux binary. It hides its process name as libdalvikengine.so . It decrypts strings using modified RC4 (with added LCG/LFSR). It reads TXT and custom records from ENS/SNS, converts fake IPv6 formats, and gets distributor node IP addresses. It gets a list of infected device relays from http://<node>:9000/nodes?key=meowmeowmeow . It connects to the C2 server using a fixed 78-byte login and heartbeat. It executes DDoS commands that include duration, attack type, target, and flag. Relay-Only Chain A relay variant without DDoS features searches for UPnP-enabled gateways. It creates 155 port forwards on the WAN side and listens on its own device. It

Public Wi‑Fi DNS Poisoning: Hijacking Microsoft 365 Sessions of Business Travelers 1. Basic Information Article Title : Hacked Public Wi-Fi Gateways Used to Harvest Corporate Credentials Source : SecurityWeek Publication Date : 2026-07-27 Original Article : https://www.securityweek.com/hacked-public-wi-fi-gateways-used-to-harvest-corporate-credentials/ Primary Source : https://reliaquest.com/blog/threat-spotlight-dns-poisoning-tactics-expand-to-hospitality/ Related Entities : Microsoft 365, Entra ID device-code flow, DNS poisoning, AiTM, WPAD, captive portal, FrostArmada, APT28 (attribution unconfirmed) Severity : High IOCs : 38.146.28.75 , 31.57.243.154 , 104.194.159.150 , m365-owa.com , owa-ms365.com , ms365-device.com , ms365-live.com 2. Executive Summary This attack compromises Wi-Fi gateways at locations like hotels to forge DNS responses. It does not send phishing emails. Instead, it tricks users into visiting fake Microsoft pages, using WPAD proxies, and entering device-code authentication. This allows attackers to steal MFA-authenticated Microsoft 365 sessions. 3. Attack Flow Chain A: DNS Redirection and Credential Theft Attackers gain administrative access to captive portal gateways in hotels or conference centers. Hypothesis (Primary source confidence: Low to Medium) : Public SSH/SNMP/Web management interfaces and weak, reused administrator credentials are used for initial access. The gateway returns fake responses for DHCP-assigned DNS or passing DNS, resolving normal domains to attacker IPs. Users are redirected to fake Microsoft pages to collect credentials and OAuth information. Attackers log into Microsoft 365 using the stolen credentials and tokens. Chain B: WPAD The gateway controls wpad name resolution or DHCP option 252. The device downloads the attacker's PAC file. Windows app and browser traffic pass through the attacker's proxy. Investigations observed attempts, but successful execution is unconfirmed. Chain C: Device-Code Flow The fake page sh

FortiOS CVE-2025-68686: Bypass of Symlink Persistence Mitigation for Already Compromised Devices 1. Basic Information Article Name : CISA Adds Two Known Exploited Vulnerabilities to Catalog Source : CISA Publication Date : July 27, 2026 Original Link : https://www.cisa.gov/news-events/alerts/2026/07/27/cisa-adds-two-known-exploited-vulnerabilities-catalog Related Sources : https://fortiguard.fortinet.com/psirt/FG-IR-25-934 https://nvd.nist.gov/vuln/detail/CVE-2025-68686 Related Entities : CVE-2025-68686, FortiOS, SSL-VPN, symlink persistence, CISA KEV Severity : Critical 2. Summary This is an actively exploited vulnerability. An attacker who has already compromised the FortiOS file system via another vulnerability can use a crafted HTTP request to bypass symlink persistence mitigations. This allows access to sensitive files through the SSL-VPN web interface even after an upgrade. 3. Attack Flow An attacker compromises FortiOS down to the file system level using another vulnerability or path. The attacker places a symlink pointing to out-of-bounds system files into the SSL-VPN related area. An administrator applies standard patches or firmware updates, but the malicious symlink or its recreation path remains. The attacker bypasses the mitigation using a crafted HTTP request via CVE-2025-68686. The attacker may read sensitive files such as configurations, credentials, and keys from the SSL-VPN web interface. The attacker may use the stolen information to continue VPN authentication, administrative access, and internal intrusion. 4. Attacker Position and Execution Location Initial compromise and symlink placement happen on the FortiGate/FortiOS device. Mitigation bypass and file reading occur externally via the SSL-VPN HTTP(S) interface. This CVE alone does not provide initial file system access to uncompromised devices. 5. Visibility for Victims and Administrators The device may look updated, but unauthorized symlinks can remain. Crafted HTTP requests to the SSL-VPN w

Certighost CVE-2026-54121: Low-Privilege Users Impersonate a DC via AD CS 1. Basic Information Article Title : New Certighost PoC exploit lets attackers hijack Windows domains Source : BleepingComputer Published Date : 2026-07-27 Original Article : https://www.bleepingcomputer.com/news/security/new-certighost-poc-exploit-lets-attackers-hijack-windows-domains/ Primary Source : https://gist.github.com/H0j3n/a5ef2609b5f2944ac2390a191a534c26 Related Entities : CVE-2026-54121, Certighost, Microsoft AD CS, Enterprise CA, PKINIT, Kerberos, DCSync, Impacket Severity : High 2. One-Sentence Summary A public PoC allows a low-privilege domain user to point AD CS "chase" references to an attacker host, trick the CA into trusting fake LDAP/LSA responses to get a Domain Controller certificate, and then take over the entire domain using PKINIT and DCSync. 3. Attack Flow An attacker connects to LDAP with a low-privilege domain account and lists CAs, DCs, and Domain SIDs/GUIDs. The attacker uses the default ms-DS-MachineAccountQuota=10 setting to create a computer account and register an SPN. The attacker starts fake LDAP and LSA services on their host. The attacker specifies their host in the certificate request's cdc (Client DC) field and the target DC in the rmd (Remote Domain) field. The CA connects to the attacker-specified cdc via SMB/LDAP to chase the reference. The attacker's service relays the CA's authentication challenge to the real DC and returns the target DC's objectSid and dNSHostName . The vulnerable CA treats the returned data as authoritative and issues a certificate containing the target DC's SID and DNS name. The attacker uses PKINIT to get a Kerberos TGT as the DC and saves it to a .ccache file. The attacker performs a DCSync using the DC account's replication rights to steal secrets, including krbtgt . 4. Attacker Position and Execution Location The attacker needs a host inside the domain with valid authentication that can reach the CA, DC, and SMB/LDAP ports. T

MedusaHVNC: Remote Control of Logged-in Browsers on Hidden Windows Desktops 1. Basic Information Article Title : MedusaHVNC Malware Uses Hidden Windows Desktops to Evade Detection Publisher : SecurityWeek Publication Date : 2026-07-27 Original Article : https://www.securityweek.com/medusahvnc-malware-uses-hidden-windows-desktops-to-evade-detection/ Primary Source : https://www.blackfog.com/medusahvnc-a-hidden-desktop/ Related Entities : MedusaHVNC, MaaS, HVNC, JScript, AutoIt, charmap.exe , ChaCha20, Chrome/Edge/Firefox Severity : High IOCs : 51.89.204.28:4444 , %TEMP%\Nx2981Okkr2\ , AFLlvOscPj.bat , zorsxklxfehdoals 2. Executive Summary This is a RAT that uses JScript, AutoIt, charmap.exe injection, and multi-layer decryption to open logged-in browsers on a hidden Windows desktop invisible to the user. It controls existing cookies and sessions using the victim device's original IP address. 3. Attack Flow wscript.exe runs an obfuscated JScript file and waits for 7,584 milliseconds. It extracts the AutoIt execution system, configuration, and encrypted payload to %TEMP%\Nx2981Okkr2\ . It places AFLlvOscPj.bat in the Startup folder for persistence. AutoIt decrypts the payload using single-byte XOR 0xAE . It starts the legitimate C:\Windows\System32\charmap.exe and injects the loader into it. It decrypts the final x64 PE file using 16-byte repeating XOR and ChaCha20. It makes a custom TCP connection to 51.89.204.28:4444 . It creates another hidden desktop and launches Chrome, Edge, or Firefox. It captures screens using BitBlt and PrintWindow , sends inputs using SendInput , and moves data using the Clipboard API. It uses cookies and sessions from existing browser profiles to control user accounts. 4. Attacker Position and Execution Location The attacker uses a MaaS operation panel and C2 server. The loader and HVNC run on the Windows device, and the browser runs on a separate desktop invisible to the user, but on the same device, IP, and profile. The initial delivery ve

VeloCloud Orchestrator CVE-2026-16812: Unauthenticated OS Command Injection Actively Exploited 1. Basic Information Article Title : Arista patches VeloCloud Orchestrator zero-day exploited in attacks Source : BleepingComputer (Primary Source: Arista Security Advisory 0144) Publication Date : 2026-07-27 Original URL : https://www.bleepingcomputer.com/news/security/arista-patches-velocloud-orchestrator-zero-day-exploited-in-attacks/ Related Sources : https://www.arista.com/en/support/advisories-notices/security-advisory/24364-security-advisory-0144 https://www.cisa.gov/news-events/alerts/2026/07/27/cisa-adds-two-known-exploited-vulnerabilities-catalog Related Entities : CVE-2026-16812, CWE-78, VeloCloud Orchestrator (VCO) On-Premises, VeloCloud Edge, CISA KEV Severity : Critical IOCs : 8.19.75.217 , 206.72.242.124 , 206.72.242.162 2. Summary This is a CVSS 10.0 vulnerability. It allows an unauthenticated attacker to access the Web UI of an internet-reachable on-premises VCO. The attacker can execute OS commands through internal-only functions. Active exploitation has been confirmed. 3. Attack Flow An attacker searches for a VCO Web interface. The attacker sends a crafted request without authentication to reach internal-only functions. The attacker executes commands on the VCO host via OS command injection. The attacker may access configurations, device lists, credentials, certificates, keys, and databases. The attacker proceeds to create files, export databases, create archives, perform outbound communications, and change management configurations. Inference : The attacker can abuse the authentication and configuration paths to Edge devices managed by the VCO, expanding the impact to the entire SD-WAN. 4. Attacker Position and Execution Location The attacker is an external host with network access to the VCO Web UI. The initial request targets the web layer. Commands execute on the on-premises VCO host. Hosted and Dedicated VCOs are already patched. VeloCloud Gateways

TL;DR Modern web applications change constantly. Components are re-rendered, generated...

Use a private bucket with short-lived presigned URLs when an avatar belongs to exactly one user, and reach for a public CDN-backed bucket only when the images are genuinely public and you'd rather pay for cache hits than for signatures. For a Node.js SaaS that is the entire decision, and everything after it is plumbing: which S3-compatible provider you point at, how long a signature should live, and what happens to the stored object on the day a user deletes their account. Avatars are small. That removes half the hard problems. The half that's left is the half I get paged for, because an avatar key is written by an untrusted client, read on nearly every page render, cached in three places you don't control, and referenced from a database row that has its own opinion about which object is current. So the questions I ask a storage vendor aren't about upload throughput. They're about whether a partial write can ever be visible to a reader, what the durability number is actually measuring, and how I reconcile the bucket with my user table after a failed deploy. I've never watched a team lose avatar bytes. I've watched several lose track of which bytes were current, which is the same outage with a friendlier root-cause section. How should a Node.js SaaS store private user avatars in object storage? Three moves, in this order. Create one private bucket for the whole tenant base, write each avatar under a key that carries a random component, and mint a presigned GET at display time instead of persisting any URL. Store the key in your database, on the user row, and nothing else, because keys are stable and signatures expire — a URL you saved last Tuesday is a support ticket waiting to happen. Serving the image then costs you one signing call per render, which you can cache in Redis for slightly less than the signature's own lifetime. That random component does more work than it looks like it does. Overwriting a fixed path like users/8821/avatar.png puts you in a read-modify

If you just want the recommendation: call a plain REST image generation endpoint from your Node.js backend, keep the prompt-in / image-out path as dumb as you can stand, and add a chat model on top only when you actually need policy checks or structured prompts. For a first text-to-image feature inside a SaaS app, that is the entire architecture worth building. I've shipped that feature twice. Both times the generation call was the boring part. What ate the calendar was everything around it: deciding whether the output was safe to show a paying customer, reading the licence terms closely enough to know we could put generated art in a customer's exported PDF, storing the result somewhere that wasn't the provider's temporary URL, and — the part I got wrong, which I'll come back to — making retries safe. I run a one-person company, so I optimise for the number of moving parts I have to keep in my head at 2am, and a text-to-image feature that pulls in three new vendors is a feature I'll quietly regret. Your priorities may be different if you have an infra team. What should I look for in a text-to-image API for a SaaS app? Four things, in the order they'll actually hurt you. Model availability in your regions comes first. If you sell into both the US and the EU, check that the model you pick is served in both, because "we support Europe" sometimes means the marketing site and not the inference region. Ask for it in writing if the answer matters to your DPA. Commercial use terms come second, and they're the ones nobody reads until legal asks. Most of the big image models now permit commercial use of outputs, but the details differ on who owns the output, whether you can train on it, and what happens with likenesses and trademarks. Read the actual terms page for the model, not the aggregator's summary of it — aggregators route to several vendors and the upstream licence is what governs your PDF. Then pricing shape. Per-image billing is easy to model in a spreadsheet; per-s

After a domain migration or HTTPS switch, "all plugin settings are gone" or "Elementor layouts are broken" is a common outcome. The cause, in most cases, is running a string replacement against the WordPress database without accounting for PHP serialized data. WordPress stores plugin configurations, custom field values, and widget settings in PHP’s serialized format. Standard SQL replacements — phpMyAdmin’s find-and-replace, raw UPDATE statements, sed on a .sql dump — rewrite the string value without updating the length metadata that serialization embeds alongside it. The result is a database that appears intact but returns false on every read of the affected values. wp search-replace handles this correctly. Understanding why makes the pre- and post-execution steps more deliberate. What PHP serialization stores alongside the value A serialized entry in WordPress looks like this: a : 2 : { s : 4 : "home" ; s : 22 : "http://example.com/top" ; s : 5 : "title" ; s : 8 : "My Site" ;} The segment s:22:"http://example.com/top" means "a string of 22 bytes." The s:N: prefix records the byte length. When a simple string replacement changes http://example.com to https://example.com : Before: s:22:"http://example.com/top" (22 bytes) After: s:22:"https://example.com/top" (23 bytes) The s:22 stays unchanged even though the actual string is now 23 bytes. PHP’s unserialize() detects this mismatch and returns false . The plugin reads false instead of its configuration array and behaves as though the settings were never saved. phpMyAdmin’s find-and-replace executes a SQL UPDATE at the storage layer. No PHP context exists there — it can’t know the column contains serialized data, and it doesn’t adjust the length prefix. How wp search-replace handles it wp search-replace operates at the PHP layer, not the SQL layer: Reads each column value Checks whether it’s serialized using is_serialized() If serialized: calls unserialize() to expand it into a PHP array or object Applies the string r

Anthropic founder and CEO Dario Amodei made his views clear about open-weight models and China's growing AI capabilities.

AI assistance disclosure: This article was drafted with the help of Claude. All technical content, design decisions, code references, and screenshots reflect production systems I designed and operate at airCloset; the prose was revised by me prior to publication. Hi, I'm Ryan , CTO at airCloset (a fashion-rental subscription service based in Japan). "Everything changes with AI" is the prevailing mood. My experience building and then running an internal AI platform (cortex) points the other way. The principles don't change at all. Only the machinery does. This post is about what I've come to treat as principle, what I've concluded should be broken, and the thinking behind that split. Disclaimer : "cortex" in this article is the internal codename for the AI platform built in-house at airCloset. It is unrelated to existing commercial services like Snowflake Cortex or Palo Alto Networks Cortex. I've written about the individual pieces before: code-graph , product-graph , db-graph , biz-graph , AI-Observability , the auto-review harness , and Self-Healing . This post isn't about any of them. It's about the design principle sitting behind all of them, one abstraction level up, more essay than build log. The principle, in one sentence: how do we make accurate information accessible? It's an old question. Libraries, legal case books, encyclopedias, search engines — every era has had its own answer using whatever tools that era gave it. Even the technology revolutions people call "paradigm shifts" mostly just changed the means . The underlying question didn't move. Now AI has arrived, and my read (probably not a controversial one) is that its shift is at least on the scale of the internet, possibly larger. As with every previous paradigm shift, the means of answering "how do we make accurate information accessible?" will get redesigned from the ground up. That's what this post is about: AI-Native Redesign — a view where you rebuild the whole design with AI treated as a given