Changelog

Every change customers can see gets an entry here, dated on the day it reached the live service. Entries describe what changed for you, not how it was built.

Where an entry affects a documented behavior, it links to the page that explains it. For current maturity of each surface, see the Platform Maturity Matrix. For live service status, see status.dralvia.tech.

2026-10-08

• Repository scans recognise the Shai-Hulud worm and check the files AI coding assistants obey. The worm that has stolen npm, GitHub and cloud credentials since September 2025 (and in 2026 hid in Claude Code settings) is now named by its loader, its runner, its workflows and its campaign strings, as a critical finding that blocks the CI gate. A workflow that turns every secret into one piece of text is reported. Files that instruct or configure an AI assistant are now read: hidden text in AGENTS.md, .cursorrules and similar files, commands the assistant runs on its own, settings that send its traffic and your API key to another address, and MCP servers that download code. On the 1,000 most-starred GitHub repositories, none of the alarming checks matched; 44 projects' own hook commands are listed as low findings. See Repository scanning.

• SVG and HTML smuggling attachments are caught. An SVG attachment is now treated as the document it is: one that runs a script, sends you to another page or draws a sign-in form inside the image is reported (malicious when it redirects or collects input), and it goes to the sandbox like an HTML file. Before, an SVG attachment was read as an ordinary file and stayed clean. An HTML attachment that carries a file inside itself and has the browser save it (HTML smuggling) is now named as malicious; before, it was scored like any HTML file. Ordinary SVG logos stay clean (none of 37,065 tested matched). See Email Protection.

• More hosting platforms are recognised as hosting for other people's sites. 33 platforms the threat feeds listed phishing on this year, including the AI app builders Lovable (lovable.app), Bolt (bolt.host) and Framer AI (framer.ai), Square Online (square.site) and Tencent EdgeOne, now count each subdomain as its owner's own site rather than part of the platform. See How web scans work.

• Repository scans catch three attacks that hide from code review. A GitHub Actions workflow that pastes an issue title, pull request text or branch name into a command, or that runs a pull request's own code with the repository's secrets, is now reported (anyone who can open an issue could otherwise run code in the pipeline). Code hidden in invisible characters (the GlassWorm technique) and text-direction tricks (Trojan Source) are reported too. A dependency version published as malware, such as [email protected] from the September 2025 npm compromise, is now critical and blocks the CI gate; before, it showed as a medium warning. Also fixed: workflow findings were counted twice, and .yaml workflows were missed by the runner and secret checks. See Repository scanning.

• Fake Ledger, Trezor and Exodus wallet pages are recognised. These three hardware and software wallets were not in Dralvia's brand list, because their names are also ordinary words ("ledger" is accounting software and a newspaper, "trezor" means treasury in Serbian and Czech). Of 1,227 wallet-shaped addresses Dralvia had scanned, 52 were rated Safe with no brand finding, for example fake "Ledger Live" download pages on free hosting. The three brands are now in the list, matched only in ways that do not accuse ordinary sites: the name alone in an address counts on free hosting but not on a registered site such as sql-ledger.org, and a plain one-letter misspelling or the same name under another ending does not count. See How web scans work.

2026-10-07

• Scans refuse every address that hides an IPv4 address inside IPv6. A link whose site resolves to an address such as ::ffff:100.64.0.1 could reach a carrier-grade NAT or relay network the scanner must never contact; it now ends as Blocked IP, like private and loopback addresses already did. Ordinary sites are not affected. See When a site cannot be scanned.

• Stripe's own pages are recognised as Stripe. A link in an email from Stripe (through Stripe's link-tracking address) opens Stripe's sign-in page, which offers "Sign in with Google". Because Stripe was not in Dralvia's brand registry, that page counted as a sign-in form beside another brand's name on an unknown site, and scored Avoid 100. Stripe is now in the registry, so every stripe.com address is Stripe's own: the same link scores Safe. Addresses that only look like Stripe are still checked: a Stripe look-alike next to words like "login" or "verify", or Stripe's name in front of someone else's domain, is still reported. See How web scans work.

• Self-hosted: the monthly server-rebuild bundle exports PostgreSQL instead of copying its files. A file copy of a running database cannot be relied on to restore, and on 2026-10-01 archiving it failed the whole bundle. Every PostgreSQL database is now exported with pg_dump, a failed archive records tar's own error message, and the server keeps only the newest bundle (older ones are removed only after a new one is written). See Backup Retention and Restore.

• Browser extension 1.1.3: the wallet review covers five more chains. In a workspace with wallet warnings on, transactions and permits on Sonic, Linea, zkSync, Scroll and Fantom are now also sent for the workspace's wallet review, as they already were on Ethereum, Binance Smart Chain, Polygon, Arbitrum, Optimism, Base and Avalanche. Before, requests on these chains got only the checks on your device. Download 1.1.3 from your workspace to get it. See Browser extension.

• Smart contract scanner: new launchpad tokens on Base and Ethereum are found without the explorer. Most new tokens on Base and Ethereum launch in Uniswap v4 pools created by a few launchpads, each with its own fixed pool settings. Dralvia found these pools only through the block explorer, which often does not answer, and then reported "could not be checked". The most-used launchpad pool settings are now checked directly: of 1,849 new v4 pools on Base in five hours, 1,016 are now found this way, against 42 before. See How smart contract scans work.

• Smart contract scanner: a sale refused only by the test is no longer called a honeypot. Some Uniswap v4 pools refuse a buy and a sell in the same transaction, which is how the sell test trades, while holders who sell later are not refused. One such token read as a honeypot (Avoid, block) although 31 sales by different wallets had gone through in its pool in the previous hours. When a v4 sale is refused, Dralvia now reads the pool's recent trades: if at least 3 different wallets traded each way, the token is reported as restricted, with what was seen, not as a honeypot.

2026-10-06

• Smart contract scanner: more new Uniswap v4 tokens are found and sell-tested. A token whose pool is a Uniswap v4 pool with a hook or an unusual fee is found through the pool's creation record. Since 2026-10-05 that lookup missed every token listed second in its pool: every pool against the network's own coin, and pools against WETH when the token's address sorts after WETH's. Those tokens read "no liquidity" and were not sell-tested. Both of a token's sides are now looked up, and the cheapest v4 pools are tried first. A loss that the pool's own fee explains (some v4 pools charge up to 95% a swap, and anyone can create one) is reported as the pool's fee, not as a costly exit of the token. Of 12 new Ethereum v4 tokens checked, 6 had been missed; now all 12 are tested: 11 sell back and one refuses the sale. See How smart contract scans work.

• Smart contract scanner: the result page shows the buy-and-sell test. Every contract result already carried the test, but the page showed only "Can Sell" and the taxes. A Buy-and-sell test block under Trading Controls now shows what happened, the exchange and pool it traded in, what the round trip lost, both losses for a thin pool, a costly exit, and the reason a refused sale or buy gave. See How smart contract scans work.

• Smart contract scanner: Linea, zkSync Era and Scroll are supported. Contracts on these three networks can now be scanned. Choose the network as the chain. Liquidity is looked for, and the buy-and-sell test runs, on the main exchanges of each: Etherex, Lynex, Nile and PancakeSwap on Linea; Uniswap, PancakeSwap, SyncSwap v3, Mute and zkSwap on zkSync Era; HoneyPop, Nuri, Zebra and SushiSwap on Scroll. Of 39 tokens we checked, one per exchange, 38 were found and tested. The other trades only on iZiSwap, which is not read yet. SyncSwap's classic pools, where much of zkSync Era's liquidity sits, are not read yet either. See How smart contract scans work.

• Smart contract scanner: Velodrome and more exchanges. On Optimism, Dralvia did not read Velodrome, which holds most of the network's liquidity, and its Uniswap-V2 lookup asked the wrong contract. Of the value in Optimism's 60 busiest pools, 32% was on exchanges Dralvia read; it now reads 97.5%. ApeSwap and SushiSwap v3 were added on BNB Chain (now 100%), PancakeSwap v3 and Camelot on Arbitrum, Pharaoh's Liquidity Book and classic pools on Avalanche (79% to 95%), and Ramses and W-DEX on Polygon.

• Smart contract scanner: a thin or idle pool is no longer read as a warning. A well-known token whose only pool Dralvia could read was very small lost 98% on the test sale, and was about to be reported as unsafe to sell. When a round trip loses 10% or more, Dralvia now repeats it a hundred times smaller. Fees and taxes cost the same share at any size, while a thin pool's loss shrinks. If the small trade is cheap, the result says the pool is thin instead of calling the exit costly. A pool that holds the token but trades nothing at the current price no longer counts as liquidity. Before, a failed buy in such a pool read as "buyers blocked".

• Smart contract scanner: Sonic is supported. Contracts on Sonic, the network that replaced Fantom, can now be scanned: choose Sonic as the chain. Liquidity is looked for, and the buy-and-sell test runs, on Shadow, SwapX, Equalizer, Metropolis, Defive, SpookySwap, SushiSwap, Oku and Wagmi. Of 12 tokens we checked across 11 Sonic exchanges, all were found and tested. Pools on Beets and Curve are not read yet. Sonic has no free block explorer, so a contract's verified source comes from Sourcify, and its age and deployer history are not shown. See How smart contract scans work.

• Wallet review: payments to a look-alike address are blocked. Address poisoning puts an address that shares the first and last characters of one you use into your history, and waits for you to copy it. Two such mistakes cost one sender about $50 million in USDT (December 2025) and another about $68 million in WBTC (May 2024). When a wallet review includes the sender, Dralvia now checks the sender's recent payments. If the recipient only looks like an address they have paid, and is not one of them, the result is "block" and names both addresses. Replayed against both senders' real history, both payments are blocked. See Pre-sign review.

2026-10-05

Smart contract scanner: tokens launched against ZORA, VIRTUAL, ARB and WBTC are read. Many new tokens trade only against another established coin. Examples are Zora coins against ZORA and agent tokens against VIRTUAL on Base, and tokens against ARB, WBTC or UNI on Arbitrum. Their pools were not looked up, so they were reported as having no liquidity and could not be sell-tested. In new pools we checked on five networks, 9 of 258 were like this. Pools against ZORA, VIRTUAL and cbBTC on Base, ARB, WBTC and UNI on Arbitrum, and WBTC on Polygon are now found, and the buy-and-sell test reaches them through that coin's own pool. Only a short list of established coins is used, so a pool against a little-known coin still does not count as liquidity. See How smart contract scans work.

Smart contract scanner: a costly exit and a days-old token are now scored. A token deployed the day before could read Safe, even though selling it back through its pools returned only about 83% of what was paid. Its pools, like many on Uniswap v4, keep a large fee on every trade. The honeypot test only measured the token's own tax. It now also measures the whole round trip, including pool fees, any fee a v4 hook keeps, and both taxes. When the round trip loses 10% or more, the token's other pools are tried and the cheapest is reported. If even the cheapest loses 10% or more, the result says how much came back and the score rises. If it loses half or more, the sell is reported as unsafe. A contract deployed in the last 3 days now also scores higher, because rug pulls and honeypots cluster in a token's first days. The contract's age was often missing, on Base and Optimism for example, because the nodes there no longer keep old blocks. It is now read from the explorer's creation record. When the network's explorer does not answer the Uniswap v4 pool lookup, the result now says "Liquidity could not be checked" instead of "No liquidity detected". When neither the pools nor a sell could be checked, the result stays at least Caution and says to scan again later. See How smart contract scans work.

Smart contract scanner: Uniswap v4 pools with hooks, and Blackhole on Avalanche. Many new tokens trade only in Uniswap v4 pools that use hooks or unusual fees. Dralvia did not find those pools, so the tokens were reported as having no liquidity and could not be sell-tested. When a token has no other pool, Dralvia now finds its v4 pools from their creation records and runs the buy-and-sell test in them. Blackhole pools on Avalanche are now found too. See How smart contract scans work.

Smart contract scanner: Aquaspace on Avalanche is read. Tokens that trade only on Aquaspace were reported as having no liquidity, which counts against them, and could not be sell-tested. Their Aquaspace pools are now found, and the buy-and-sell test runs in them. See How smart contract scans work.

Smart contract scanner: every network has a backup node. Six networks were read through a single public node. When it failed, contract scans on that network came back with liquidity and sell checks marked "could not be checked". On Avalanche, the node had begun refusing our requests. Each network now has at least two nodes, and Dralvia checks every hour that each network still has one that answers.

Smart contract scanner: the honeypot test now reaches v3, v4, Aerodrome and Liquidity Book pools. The test that buys a token and tries to sell it back used to work only through a Uniswap-V2 style router. Tokens that trade on Uniswap v3 or v4, PancakeSwap v3, Aerodrome, QuickSwap v3 or Trader Joe Liquidity Book were never tested. On Avalanche, ordinary tokens were wrongly described as refusing a buy. The test now trades directly with the token's own pool. Of 47 widely traded tokens we checked, 38 are now tested, up from 20, and the Avalanche tokens are tested normally. A token that passes the test no longer scores slightly higher than one that was never tested. Tokens that trade only in Uniswap v4 pools with hooks are not tested yet. See How smart contract scans work.

Browser extension 1.1.2: marketplace orders and batch permits. The wallet guard now reads OpenSea (Seaport) and Blur order signatures before your wallet shows them. It stops an order that gives away items from your wallet and pays you nothing, and flags one where most of the payment goes to someone else, one that offers any token of a collection, and Blur bulk signatures that hide their orders. It also flags Permit2 batch and signature-transfer permits and unlimited DAI-style permits. These checks run on your device.

Wallet review: plain payments to a wallet are no longer a review case. Sending a network's coin to an ordinary wallet came back "needs review" every time, because a wallet has no source code to read. It is now "allow", labelled "A plain payment to a wallet", unless the wallet is on a known-bad list. Payments to contracts keep the full review.

Browser extension 1.1.1: the wallet guard blocks again, and checks signatures.

• In version 1.0.26, choosing Block on a risky wallet approval did not stop it: the request still reached the wallet. The risk check behind that dialog also never got an answer, so the dialog did not open in practice. Both are fixed: Block now rejects the request as the wallet's own Reject button would.
• The guard now checks signature permits (EIP-2612 and Permit2), raw-hash signatures, EIP-7702 account hand-overs and batched calls, not only approvals sent as transactions. These checks run on your device, with or without an account.
• In a workspace with wallet warnings on, each request is also checked by the workspace's wallet review, including Dralvia's known-bad address lists.
• Workspaces download 1.1.1 from the extension download page.

Smart contract scanner: a liquidity check that fails partway says so. When a node stopped answering while Dralvia read a token's main trading pair, the token could read "No liquidity detected". It now reads "Liquidity could not be checked". A pair that holds liquidity also counts when none of it has been burned.

2026-10-02

Smart contract scanner: Polygon and Avalanche liquidity, and a working Polygon node.

• Polygon contract scans used a public node that had stopped answering, so most Polygon tokens read "No liquidity detected" whatever they held. Scans now use nodes that answer, and switch to another node when one fails. Base also gained two backup nodes.
• When no node answers, the result now says "Liquidity could not be checked" instead of "No liquidity detected".
• Liquidity is now found on Polygon on Uniswap v3 and v4, QuickSwap v3 and Uniswap V2, and on Avalanche on Uniswap v3 and v4, Trader Joe Liquidity Book, Pharaoh and Pangolin v3. Polygon pairs against USDT were never found because of a wrong token address; fixed.
• On 12 tokens from Polygon's busiest pools, "No liquidity detected" went from 9 to 0.

Unified scanner: file hash lookups fixed. Where a VirusTotal key is configured, a pasted file hash came back "VirusTotal lookup error" every time because of a coding fault. The lookup now returns the engines' verdict and a score.

Smart contract scanner: liquidity on Uniswap v3/v4, PancakeSwap v3 and Aerodrome is seen.

• Tokens that trade on newer exchange pools were reported as having no liquidity, which raised their score; on Base no exchange was read at all. Of 24 tokens from the busiest pools, 16 were reported without liquidity, some as Avoid. Dralvia now finds those pools, and says "Liquidity could not be checked" when the chain does not answer instead of "No liquidity detected". See How smart contract scans work.

Smart contract scanner: a renounced owner's powers stop counting, when proven.

• Tokens whose ownership was renounced were still scored for powers only the owner could use, such as blacklisting (PEPE was Caution). Dralvia now simulates those functions and, when only the renounced owner address could ever call them, stops counting them. PEPE and similar tokens now score Safe. Limits that are already set still count. See How smart contract scans work.
• Ethereum lookups of verified code and history now fall back to a second free explorer when the first is busy.

Smart contract scanner: fewer false alarms on well-known tokens, transaction hashes are read again, and explorer gaps are named.

• A transaction hash pasted into the unified scan returned "TX lookups not configured" on every chain, because the block explorer address it used was retired. It is now read from the chain itself, so the call is decoded and its outcome shown. See Wallet and transaction scanner.
• Well-known tokens governed by a multisig or a timelock were scored Caution for powers their owner holds (CAKE was Caution 58). The result now names who controls the owner, and those powers count half when the owner answers to a multisig needing two or more signatures or a timelock of 24 hours or more. A privileged wallet holding a tiny share of supply no longer adds risk. Some tokens whose owner is a single wallet that can mint without limit now score higher on BNB Chain, because that power is now visible. See How smart contract scans work.
• On BNB Chain, explorer lookups had been failing without saying so, and results called well-known verified contracts "not verified". Verified source code is now read from Sourcify, and when no source can be checked the result says so instead of calling the contract unverified. Deployer history is still not available on BNB Chain. See How smart contract scans work.

2026-10-01

Smart contract scanner: fewer false alarms on new tokens, and known-bad addresses are blocked.

• Tokens created on four.meme (BNB Chain) were scored Avoid because the launchpad that creates them owns them and holds their unsold supply. Dralvia now recognises launchpad tokens, and no longer reports minimal-proxy clones as upgradeable. See How smart contract scans work.
• Addresses on the US Treasury sanctions list (OFAC SDN) are now known to the contract scanner and the pre-sign review: a listed contract is Avoid, and a signing request that involves a listed address is blocked, even when other parts of the review are uncertain. See Pre-sign review and the contract scanner API.

Smart contract scanner: honeypots are found by trying to sell.

• For tokens with a V2-style pool, Dralvia now simulates a small buy and sell (nothing is sent to the chain). A token whose sell is refused is reported as a honeypot and Avoid, and the measured buy and sell taxes are shown. See How smart contract scans work.

Scanner: fake "Send USDT" pages are recognised.

• Pages that copy a wallet's send screen but ask for an approval to spend your tokens, and report your wallet to a Telegram bot, are now flagged (content:wallet_approval_exfil, Avoid). See How web scans work.

Scanner: fake "I'm not a robot" boxes are pressed even when the sandbox is busy.

• When the browser sandbox found a fake verification box but could not click it in time, it skipped the box, and a page that copies a command on that click could go unnoticed. It now presses the box another way, and the API reports how (verification_click.how). See Web2 scanner API.

2026-09-30

Scanner: the OpenPhish phishing feed is read again.

• OpenPhish moved its free feed behind a web redirect, and the scanner did not follow it, so its listings had not been checked since August. Pages OpenPhish had already listed could be scanned and reported Safe. The feed is followed again, and a feed that returns something that is not a feed (PhishTank's download currently returns an image) is reported as unavailable rather than as "not listed".

Scanner: texting-scam pages are looked at as a phone.

• Unpaid-toll, DMV and parcel text messages lead to pages that show a computer a blank page or send it elsewhere. When the desktop view of a page is thin, the browser sandbox now looks again as a phone (touch, phone screen, iPhone) and records what the phone saw. See How web2 scans work.

Scanner: the list of abused domain endings was re-measured.

• Endings that phishing uses far more than ordinary sites were added: .cfd, .lat, .ink, .life, .cloud, .buzz, .pics, .digital, .wiki, .surf, .garden, .courses and .christmas. .quest, .space, .monster and .ml were removed. The ending adds a small amount to a score and helps confirm other evidence; it never decides a verdict on its own.

Scanner: page data and old-browser pages are not evasion.

• Sites that embed their page data as escaped text (for example JSON.parse("...\u002Fcars\u002F...")) were reported as having a "packed or heavily encoded script". Data escapes punctuation such as /, < and >; code that is being hidden escapes its letters. Only escaped letters and digits count now. Across 370 ordinary sites the finding fell from 7.3% to 2.4%.
• A page that sends browsers too old to run it to its own /oldbrowser.html page was reported as a redirect gated on the visitor's browser. A navigation to a fixed page on the same site no longer counts; one to another site, or to an address the script builds, still does. renault.co.uk scored Caution 46 and now scans Safe.

Scanner: a "follow us" link does not make a page look like Facebook.

• The scanner reports brand names it finds in the text a visitor can read. The words of a link that names the site it points to ("Facebook" linking to facebook.com, "Get it on Google Play") no longer count: that is a site linking to its own profile. The names "Live", "Office", "Crypto" and "Coins" count only when the page writes the brand's full domain ("Crypto.com"), since as plain words they name nothing. Across 369 ordinary sites, pages with a brand name reported fell from 53% to 33%.
• One phishing page in our sample, a WeTransfer copy, had been scored Avoid partly because its copied footer named Facebook and Instagram. It now scores Caution: it is still flagged for its fake sign-in flow and for capturing credentials, but it no longer carries a brand name it was not imitating.

Scanner: an online shop is not a fake sign-in page.

• The scanner looked for sign-in providers in the page source letter by letter, so "SSO" (single sign-on) was found inside "accessories", "assorted" and "espresso", on about three in five ordinary sites. A page whose only "provider" was SSO was then reported as a fake sign-in flow. Providers are now matched as whole words, and a fake sign-in flow needs a named provider (Google, Microsoft, Apple, ...) offered on a site that is not that provider's.
• "Amazon lure" now needs the word Amazon where a visitor can read it. The name inside asset addresses and script names no longer counts, and "gift card" or "your order" alone is not an Amazon lure. tervis.com, a shop registered in 1996, scored Avoid 98 and now scores Caution 40: its sign-in form still saves what is typed into the browser, and it has a hidden frame.
• "Delayed redirect" now needs the timer to fire the navigation. A slider's timer in the same script as an ordinary link click no longer counts.

Scanner: more of what phishing pages hide is found.

• A password field on a page that loads EmailJS, a service that emails form contents straight from the browser, is now reported as credentials sent to an outside service. A contact form using EmailJS is not.
• Fake "verify you are not a robot" pages that copy a command for you to paste into Win + R are recognised when the command is kept in the page's markup rather than its scripts, when it is written as %COMSPEC%, | bash or base64 -d, or split with ^ characters.
• A page that looks up the visitor's IP address (with services such as ipapi.co) next to a password field is now reported. Phishing kits do this to turn away scanners or to send the victim's location with the password. A phone-number field that picks the visitor's country flag this way does not count.
• A field asking for a national ID or tax number (CPF, SSN, DNI, codice fiscale and similar) now counts like a password field when the page also uses lure phrases such as "confirme sua identidade". The field alone is never a finding: banks and government sites ask for these numbers too.

Scanner: Google Sites pages are judged on their own.

• Every page on Google Sites scored Avoid 80, because a threat feed lists one Google Sites page and the listing counted against all of them. On a site where anyone can publish, a listing now counts only for the listed page and the pages under it. Other pages show it as "malicious files have been hosted on this domain", which is true, instead of being convicted by it.
• Fake "verify you are not a robot" pages placed in a Google Sites embed block, or in any frame whose whole page is written inside the frame tag, are now found, including ones that keep their instructions as encoded text. The report shows the command the page copies. Such a page is flagged as Avoid even on a platform we otherwise trust.

Scanner: this year's paste-and-run variants and device-code phishing.

• Paste-and-run pages now also count when the copied command uses nslookup, rundll32, msiexec, wmic, schtasks, cscript, wscript, regsvr32 or macOS osascript, and when the page tells you to open Windows Terminal (Win + X), paste into the File Explorer address bar, open Terminal on a Mac, or dresses up as Google's "unusual traffic" page. Lure wording written with look-alike Cyrillic or Greek letters, or with invisible characters, is read as the words it shows.
• A page that shows a sign-in code with a "Copy code" button and sends you to Microsoft's, Google's or GitHub's real device sign-in page is now reported as device-code phishing (content:device_code_lure). Entering such a code signs the page owner in as you, without your password or second factor. The providers' own pages are not flagged.

Scanner: the browser sandbox takes the page apart.

• In a full review the sandbox now reads every frame of the page, not only the top one, and records anything the page copies to the clipboard. If a frame shows an "I'm not a robot" box, the sandbox presses it once, which is when a paste-and-run page copies its command. A shell command on the clipboard, or a paste-and-run page in any frame, is reported with the command shown. What else frames contain is listed in the evidence without changing the score. See How web2 scans work.

Scanner: older phishing tricks are checked as well.

• A sign-in page that loads your company's logo, taken from the email address you arrived with, is reported (content:victim_branded_login). Across 3,705 ordinary sites this never appeared; on 601 feed-listed phishing pages it appeared 12 times, each next to a password field.
• A page shipped as one long base64 block and written out when it loads is now read as the page it becomes. The block is decoded as text and never run.
• An address such as facebooklogin123.blogspot.com counts as a brand name with a login word, as facebooklogin.blogspot.com already did. The trailing number used to hide it.
• A link such as https://[email protected]/ shows one site and opens another: everything before the @ is ignored by the browser. The scan already checked the site the link really opens; it now also says the link was disguised (url:userinfo_disguise).
• An address that reads as a government site but is not, such as txdmv.gov-lska.win from unpaid-toll and DMV text messages, is now scored (domain:fake_government_address). It only counts under new generic endings such as .win or .cfd, where no government registers; genuine addresses of the same shape under country endings are left alone.
• Brands registered under a two-part country ending, such as barclays.co.uk or rakuten.co.jp, were not matched when their name was placed in front of someone else's domain (barclays.secure-login.example), in a certificate's other names, or in the page's text. They are now.

Scanner: 64 more of the most-impersonated brands are recognised.

• Look-alikes of postal and parcel services (Royal Mail, Evri, La Poste, Correos, PostNL, bpost, InPost, Poste Italiane, Canada Post, Australia Post, Correios), banks and payment apps (Revolut, Wise, Venmo, Cash App, Nubank, Itaú, Bradesco, Caixa, Mercado Pago, HDFC, ICICI, Paytm, GCash, Sparkasse, CommBank, Westpac, RBC, Scotiabank, Interac, Robinhood and others), tax and health services (HMRC, impots.gouv.fr, ameli.fr) and platforms such as Yahoo, T-Mobile, Telegram, TikTok, Zoom, Booking.com and Airbnb are now named in the evidence. For example auspost.customerservicep.com, a parcel lure that scanned Safe, now reports Australia Post.
• Many of these names are also ordinary words or are shared with unrelated businesses (a newspaper called the Telegram, the many local Sparkasse banks, "orange", "zoom", "booking"). Each brand is only matched in the ways that were checked against a million well-known sites first, so a site that merely uses the same word is not accused of impersonating it.

Scanner: the sandbox cannot be held up by a page that stops answering.

• Some pages keep a frame busy so that it never answers the browser. The sandbox's frame and clipboard checks now stop at a time limit instead of waiting, so the rest of the review is kept. Two ordinary sites whose review had been lost now complete.

API: a stored scan no longer repeats its detailed results.

• A scan result is stored with detailed_results once. The duplicate copy in tabs.details, which fresh responses already left out, is no longer stored either, so scan history and cached results no longer carry it. Read detailed_results. Stored scans are about 40% smaller.

2026-09-29

Scanner: ordinary online shops are no longer marked as cloaking.

• Store platforms and ad networks check for search-engine crawlers so they do not load tracking or ads for bots. The scanner read that as a page hiding from crawlers, and pooled it with unrelated code elsewhere on the page, so some ordinary shops and publishers scored Avoid. canadagoose.com, for example, scored Avoid 100 and now scans Safe. A page that checks for crawlers and sends real visitors somewhere else is still flagged. See How the phishing scanner works.
• The same applies to "packed or heavily encoded script": it is now judged one script at a time, so an old Google Analytics snippet on one part of a page and ordinary code elsewhere no longer add up to a finding. Across a sample of 391 ordinary sites, pages flagged this way fell from 10.7% to 5.9%.

Scanner: an ordinary sign-in page is not credential harvesting.

• A login or one-time-code form on a site outside our brand list scored as credential harvesting whenever the page also used words like "login", "password" or "account", which every sign-in page does. Those words appear just as often on legitimate sites as on phishing ones, so they no longer count as corroboration. A university press site that scored Avoid 79, for example, now scores Caution 44. A sign-in form on a freshly registered domain, behind an evasive redirect, next to lure phrases, or imitating a brand is still flagged.

2026-09-28

Scanner: a brand's own site is no longer marked down for its favicon.

• A brand's own domain could score Caution because phishing copies of its site, which Dralvia had flagged, use the same site icon. uniswap.org scored Caution 28 for this reason; it now scans Safe. Copies that use the icon are still flagged. See Reused infrastructure.

Blog footer: legal links work again.

• On blog.dralvia.tech, the footer links Privacy, Terms, DPA, Cookies, Subprocessors and Legal Notice opened a "page not found" inside the blog layout. They now open the right pages on the main site. The same links elsewhere on the site were not affected.

Research blog: past weekly reports corrected.

• Eleven weekly reports published between 1 July and 23 September 2026 named universities such as aacc.edu as impersonated brands. That was a naming error, not what attackers did (see the 26 September entry). Their brand names and the sentences built from them are corrected. Every other figure is unchanged, and each report keeps its address.

2026-09-26

Research blog: brand names in digests now need evidence.

• Daily and weekly digests name a brand as impersonated only when a scan found evidence of it in the address or on the page. Earlier digests could name the registered name closest in spelling to an address, so universities such as aacc.edu were listed as impersonated when they were not. See Dralvia Labs.
• Daily digests are no longer offered to search engines and are left out of the sitemap. They stay readable in the blog archive. Weekly reports and Labs notes are unchanged.

2026-09-25

Fixes from 13 and 14 September are back in the live service.

• An update on 17 September was built from an older copy of the service and undid part of what shipped on 13 and 14 September. It is fixed today. Nothing in your data changed.
• API keys: between 17 and 25 September, repository scan results, the CI gate, exports, the usage summary and webhook management answered 404 or 401 to workspace API keys, and the /v1/... forms of those routes did not exist. The Python and JavaScript SDK methods for them work again. See the Developer guide.
• Scan verdicts: in the same window, file-sharing platforms such as drive.google.com could again be returned as Avoid on malware listed under them, and a site redirecting to its own www address could be marked Caution. Both are fixed again. Rescan anything you checked in that window. See How web scans work.
• Security hardening from our August review is live again on every part of the service, including the rule that stops scans from reaching carrier-grade NAT addresses and the refusal of XML entity bombs in uploaded repositories.

Scans you run without an account are no longer listed publicly.

• The public "recent scans", "top domains" and "redirect chains" views listed every scan without a workspace, including ones visitors had run themselves. They now show only Dralvia's own continuous scanning. A scan you run without an account stays visible to you in your own history and to nobody else.

Hacked sites that hide their next step in a blockchain are now caught.

• Some hacked websites look up the address of the attacker's server in a blockchain smart contract, then cover the page with a fake "Verifying you are human" check that asks you to paste a command. A site reported to us this way was rated Caution 42; it is now rated Avoid, and the report names what the page does. Two new findings: content:blockchain_hosted_loader and content:sandbox_blockchain_lookup. See How web2 scans work.
• Our browser sandbox now presents itself as Chrome on Windows, so pages that show their trap only to Windows visitors show it to us too.

On the free plan, the browser extension stays in its private mode.

• On the free plan, the extension does not join your workspace when you sign in to dralvia.tech. It works without an account: it sends only the site and path of each page, never the part after ? or #, and warns on risky pages. Joining a workspace, which adds browser policy, workspace history and checks of the full page address, is part of the Starter plan and above, including the 7-day trial. See Browser extension.

2026-09-24

Dralvia Guides: plain-language help, on the blog.

• Ten guides now live at blog.dralvia.tech/guides: how the Dralvia score works, checking a link before you click, spotting a phishing email, what to do if you clicked a phishing link, fake courier, bank and tax texts, QR code phishing, fake Microsoft 365 and Google sign-in pages, crypto wallet drainers, fake online shops, and protecting your accounts with passkeys and two-step sign-in. Each one ends with a free scan box.
• How the Dralvia score works explains the three verdicts, where the points come from and what lowers a score, using the same numbers the scanner uses.

Analytics now means all analytics, and nothing is sent before you answer.

• The platform's own usage events (a page was opened, a scan started, how a signup attempt ended) are now part of the analytics answer. Before, they were sent whether or not you had said yes. Now nothing is sent while the banner is open, and nothing at all if you refuse. See Cookies and analytics.
• The cookie panel no longer has a "Console Preferences" switch. It was saved and never read, so switching it off stopped nothing. Settings you choose, such as the theme or your dashboard layout, are kept because you chose them, are written only when you change them, and are never sent to us.
• Your name is no longer copied into browser storage when you sign in, and the first sign-in tour no longer uses your email address to remember that you finished it.

The EDR agent's disable password is no longer saved in your browser.

• The downloads page used to keep the password you typed in local storage. It now only fills the sample commands while the page is open, and a copy saved by the old page is deleted. See EDR agent downloads.
• The Cookies Policy in the platform's Legal Center now names every browser storage entry the platform uses.

The SDKs are on npm and PyPI.

• npm install @dralvia/sdk and pip install dralvia-sdk now work. The source stays public on GitHub. See the JavaScript and Python guides.

Try Starter or Pro free for 7 days, no card.

• The pricing pages now offer the no-card trial, including to visitors without an account: choose the plan, create your free account, and the trial is one click away after sign-in. Nothing is charged when it ends. See Pricing.

2026-09-23

API key rate limits: the number on the page is the number you get.

• Every workspace plan is limited to 300 requests per minute, including Enterprise, which used to be listed internally at 1000. 300 is the rate our edge serves per key, so a higher figure was a promise we could not keep. No workspace was using more, and nothing we published had ever quoted the higher number. If your integration needs more than 300, ask support and we will provision it for your workspace.
• API keys now lists scans per month, keys per workspace, keys per user and requests per minute for every plan in one table. Two key caps were wrong there: Pro allows 5 keys per workspace and 5 per user, not 3 and 3.
• Requests refused for pacing do not count against your monthly quota, and the rate window is a fixed clock minute.

Your plan's request rate is now enforced per API key.

• Each API key is limited to the requests per minute its plan allows, counted in a fixed clock minute. Before this, the only limit in front of the API was a flat edge cap, so a Free Evaluation key could burst well above the 10 per minute its plan describes.
• Going over answers 429 Too Many Requests with a Retry-After header and a retry_after_seconds field, both counting whole seconds until your allowance resets. Requests refused this way do not count against your monthly quota.
• A throttled key is reported as throttled. Some paths, including SCIM, previously answered 401, which reads as "your credentials are wrong" when they are fine. Only 429 carries Retry-After: a 402 (quota spent) or a 401 (revoked key) will not start working by waiting. See API keys.

2026-09-22

One cookie question for every Dralvia site.

• The website, the blog, the docs and the platform used to ask separately about analytics cookies. They all use the same Google Analytics 4 setup, so one answer now applies to all of them, remembered for 180 days. Refusing is still one click, and you can change your answer on any site. See Cookies and analytics.

Clearer privacy notes on what the platform measures.

• Cookies and analytics now lists the usage events the platform keeps without cookies, including the outcome of a signup attempt (never the email or password), and how long web server logs are kept.

Support promises match what we deliver.

• Support replies within 48 hours, and security reports are acknowledged within 48 hours. The contact table used to list an escalation hotline, a customer success manager, and a 1-hour response time, which we do not offer. See Support & Operations.
• There is no fixed weekly release window. Planned maintenance is announced on status.dralvia.tech, and scans can pause for a short time while it runs.
• The About page now names the founder.

Phone menu works again on the website.

• On phones, the Sign In and Create free account buttons in the top bar pushed the menu button off the screen, so the menu could not be opened. The top bar now shows the logo and the menu button, and both buttons are inside the menu.

Clearer home page.

• The home page now says what Dralvia does in one line: check whether a link is safe before you click it. The paste box is the first thing you can use.
• The stated scan time now matches what we measure: a first verdict often arrives in under 30 seconds and usually within a minute, and a deeper browser review can still update the score. The page previously said "under 2 seconds".
• The scan totals on the home page now say that most scans come from our own automated threat monitoring.

Scan a link straight from the website.

• The home page and the scanner and tool pages now have a box where you paste a link. The scan starts right away in the same tab, with no need to type the link again. See Your first scan.
• Opening the platform without signing in now takes you straight to the URL scanner instead of a dashboard you cannot use yet.
• When the verdict is ready, the page scrolls to it.
• Guests now see what a free account adds to a report: download it as PDF, CSV or JSON, and keep its full evidence for 7 days instead of 1. No card needed.

Light mode: scan result panels are readable again.

• In light mode, the Investigation follow-up and Think this result is wrong? panels on a scan result showed as solid dark bars with the text hidden. They now use the light panel background, so the text, links, and the report form are visible. Dark mode is unchanged.

Contact form closes after you send it.

• After "Thank you for your feedback!" appears, the form now closes by itself. If sending fails, it stays open with your message kept so you can retry. See Support & Operations.

Docs: Cookie preferences no longer covers Ask AI.

• On the docs site, the Cookie preferences button moved to the bottom-left corner. It used to sit on top of the Ask AI button in the bottom-right. See Cookies and analytics.

2026-09-14

Repository scanner: fewer false secret and IP address findings.

• Variable and parameter names are no longer reported as secrets. In code, api_key=os.environ.get("API_KEY"), apiKey: process.env.API_KEY and type hints such as api_key: Optional[str] are references, not credentials. Real string literals are still reported, and literals the scanner used to miss (b'…', f"…", template strings, "api_key": "…" in JSON, Go :=, PHP =>) are now found.
• Version strings ("version": "1.2.3.4", AssemblyVersion("1.0.0.0"), browser user agents), specification section numbers, and SVG path numbers are no longer reported as IP addresses. Loopback, 0.0.0.0, netmasks and documentation ranges are ignored.
• IP address findings now name the address, its line, and how many distinct addresses the file contains.
• Existing scans keep their findings until you rescan. See Repository scan.

API keys can read results and carry explicit permissions.

• Repository scan detail, CI gate, SARIF and manifest exports, finding triage views, and the usage summary accept your workspace API key.
• Webhook management, finding triage changes, and secure web gateway evaluation need a permission you add when you create or rotate the key. Key management, team, billing and identity routes never accept an API key. A key missing a permission gets 403 with required_scope. See the Developer guide.

2026-07-06

Daily research digest publishing restored.

• The daily research digest resumed publishing to the research blog after a pause. Posts for the missed day were backfilled. See Dralvia Labs for how the digest is produced and reviewed.

2026-07-01

Broader coverage across scanning, email, browser, and evidence.

• Repository scanning covers more of a codebase and more risk categories, with clearer findings. See Repository Risk Scanner.
• Email Protection remediation is safer, with clearer confirmation before an action touches a mailbox. See Email Protection.
• Browser Protection shows rollout progress, so you can tell how much of your fleet is actually protected. See Browser Protection.
• Web Access Protection policies can be tested before you enforce them. See Web Access Protection.
• AI Agent Safety guardrails expanded.
• Evidence reports can be verified independently of Dralvia. See Evidence Reports.
• Escalations reach the right queue faster. See TicketBridge.
• The Labs research hub returned to the blog.

2026-06-30

Research hub quality.

• Research topics backed by reproducible, evidence-checked findings are now highlighted over unverified ones, and the Labs documentation was refreshed. See Dralvia Labs.

2026-06-29

Stronger phishing and URL detection, with clearer evidence.

• URL and phishing scans use new certificate transparency, domain history, and hosting infrastructure signals.
• Scan results explain the evidence behind a verdict more clearly. See Understanding results.

2026-06-25

Evasive redirect detection and Labs workflow.

• Phishing scan accuracy improved for evasive redirect chains and links that hide behind hosted pages. See URL & Phishing Scanner.
• The Labs research auto-draft workflow shipped.

How this page works

• An entry is added when a change reaches the live service, not when it is written. If something is announced before it ships, it is labelled Roadmap in the Platform Maturity Matrix instead of appearing here.
• Entries are newest first and dated in UTC.
• Security fixes are listed once customers are protected, described by impact rather than by exploit detail.
• Planned maintenance windows that changed nothing customer-visible are not listed here; they appear on status.dralvia.tech.