What's new in mlab.sh

mlab.sh now partners with Stealed: a domain report can show how many accounts of that domain have leaked, on request.

• On a domain report, reveal its exposure: a risk level, and the leaked accounts and passwords, split between the domain's own users and its customers' accounts, with how many came from infostealers.
• Each reveal counts against your plan: 1 domain a month on Free, 25 on Pro and Team, unlimited on Enterprise. Looking at a domain you already revealed this month is free.
• Only counts are shown, never the credentials themselves. The figures come from Stealed and are not a security audit.

Pro, Team and Enterprise organizations get a monthly recap of the exposure of their verified domains on the Infrastructure page.

• On the first days of each month, the recap of the previous month: accounts and passwords exposed, change against the month before, a daily chart and a line per domain.
• Upgrading during the month gives you your first recap the next morning.
• Exposure data is kept for 6 months, then deleted.

Stealed joins the partners page, and mlab.sh can now sell you the full Stealed platform.

• The pricing page shows what is included in your mlab.sh plan and what the full Stealed platform adds, priced on request by company size and number of domains.
• Ask for a demo or a quote from the contact page, with the new leaked credentials option.

Run the mlab agent with virtsec on your Proxmox VE nodes and follow from the workspace what runs in every LXC and VM, what weakens their isolation, what is vulnerable, and what happens at runtime.

• A Virtualization tab lists your Proxmox clusters and their nodes, with a dashboard per cluster: leads to look at first, guests to look at first, and the state of each node.
• Isolation risks of every guest, read from its configuration: privileged LXC, host folders mounted inside, PCI and USB passthrough, raw settings, hook scripts, including changes waiting for the next restart.
• Vulnerabilities of every guest and of the nodes themselves, limited by default to code that is really loaded in memory, with known-exploited ones first.
• Runtime events: program runs, outbound connections and writes to sensitive paths in guests, logins and failed logins on Proxmox, and guest changes. Anything run or written by a VM's own process on the node is flagged as a possible VM escape.
• VMs are inspected from the inside only if each node's local policy allows it; it is off by default.
• Packages of every guest, and a CycloneDX SBOM to download.
• Choose from the workspace what each Proxmox cluster reports; every node's local policy keeps the last word. One enrolment code enrols every node of a cluster.

See where a case's indicators show up in what your agents already reported, in one click, without asking the agents anything.

• Sweep in a workspace, on every case: IP addresses, address ranges, domains, URLs, hashes and CVEs are looked for in memory dumps, cluster runtime events and running images.
• Each match says where: the dump and the process, the cluster and the workload, or the image, with the matching line.
• Whole indicators only: 1.2.3.4 does not match 1.2.3.45, and a domain matches its subdomains, not look-alikes.
• The outcome is kept as a note on the case, and a new webhook event reports sweeps that found something.

A Data boundary tab shows what left the hosts of a workspace, and exports it as a signed report your customers or auditors can check on their own.

• For a week, a month, a quarter or a year: what kind of data left the hosts, how much, how often, and from which agent.
• Every answer an agent signed and mlab verified is counted, with sizes and fingerprints of result files, never the data itself.
• Download the signed report: it is signed with the key every agent pinned at enrolment, and the tab shows how to check it offline.
• The report states its limits plainly, including that agents apply no masking today.

Tag agents by site, role or environment, then review and test a whole group at once instead of host by host.

• Edit tags from an agent's menu, with the tags already used in the workspace suggested.
• Filter the Agents tab by tag, with a summary of the group: how many are online, how many differ from their policy, which agent versions run.
• Test all: a signed test of every agent of the group, with the result on each row.

Your webhooks can now tell you when a workspace agent needs attention.

• An agent offline for 15 minutes, and back online.
• An agent or one of its tools older than the latest published version.
• An agent whose running tools or allowed operations no longer match its policy draft.
• One alert per incident, not one every few minutes.

Less noise and more of what matters in the Cluster tab, from the first clusters followed in a workspace.

• Vulnerabilities the distribution itself rates as not an issue for a package are no longer reported.
• Running programs written in Go count their dependencies as loaded, so their vulnerabilities now show up.
• Health checks no longer fill the runtime events, and the first and last moments of a short-lived workload are attributed to it.
• Leads list the most urgent images first, and the image list can hide the images with nothing vulnerable in memory.
• Times are shown in UTC, and the breadcrumb names the workspace.

Run the mlab agent with k3sec on every node of a cluster and follow its security from the workspace: what runs, what is vulnerable, and what happens at runtime.

• A Cluster tab lists your clusters and their nodes, with a dashboard per cluster: leads to look at first, images to fix first, and the state of each node.
• Vulnerabilities by image, limited by default to code that is really loaded in memory, with known-exploited ones first.
• Runtime events: cluster events, process executions, outbound connections and YARA detections, filtered by source, severity, namespace or text.
• Packages of every running image, and a CycloneDX SBOM to download.
• Choose from the workspace what each cluster reports; every node's local policy keeps the last word.
• One enrolment code enrols every node of a cluster.

A service that hides its version, or shows only part of it (Apache/2), could have any vulnerability of its product, or none. Those are no longer reported as findings.

• IP ranges and domains: vulnerabilities are matched only on an exact version, such as 2.4.62 or OpenSSH 9.6p1.
• Services with a hidden or partial version are listed apart as not verifiable, never counted as clean. Unfold one to see the vulnerabilities that could apply, marked as unconfirmed and left out of the totals.
• Monitoring shows them as version not verified, and by default does not email them, send them to webhooks or file them in issue trackers.
• Organization settings, Monitoring: turn on alerts for unverifiable versions to receive everything.

The memory explorer now reads the registry, kernel objects, network activity and open files of a Windows dump.

• Network: TCP connections, listening ports and UDP endpoints with their process, closed ones included, and public addresses open in mlab.sh IP intelligence.
• Persistence: autoruns (Run keys, Winlogon, Image File Execution Options and more), services and scheduled tasks, each with its last write time.
• Registry: browse any key of the hives held in memory, values included.
• Kernel: drivers whose dispatch routines point outside their own image, process, thread and image notify routines, and hooked system services.
• Files: every file the system had open, as a folder tree with counts, filters for executables and user-writable folders, and search.
• New leads: patched ETW and AMSI functions, import hooks, modified code pages, executable pages in non-executable memory, suspended threads.
• Logon sessions with their account, module build dates and debug info, and 32-bit processes listed in full.
• More dump formats: LiME, AVML, ELF and Xen cores, hibernation files, VMware snapshots, crash dumps, EWF images and compressed archives, with paging files read when they sit next to the dump.

What you find in a dump can be pulled out and analysed in a click, from a menu on each row.

• Extract an executable image as mapped in memory, for a disassembler, or rebuilt in file layout, for PE tools.
• Dump any memory region of a process, up to 256 MB.
• Scan in mlab: the image goes to the file analysis as a private report of your organization, opened in a new tab.
• YARA rules run over process memory, long scans included, with each match ready to view or extract.

Each workspace decides how long mlab.sh keeps what its agents send.

• Pick 6 months, 3 months (default), 1 month, 2 weeks, 1 week or 48 hours when creating a workspace or in its settings.
• Indexes older than that are deleted within the hour, and each one shows when it will be. Dumps on your hosts are never touched.
• Command lines and environment values that look like passwords, tokens or keys are masked before an index leaves the host.

Agent policies, tool versions and the look of each workspace are now handled in the app.

• Edit an agent's policy in the app and download it: allowed operations, dump folders, limits.
• A tools view shows which version of each tool every agent runs, and which is the latest.
• Give each workspace an icon and a color.
• Indexing shows its progress at once and keeps going if an agent reconnects; large dumps no longer time out.

Drop-down lists across the app now show their arrow with proper spacing.

• The arrow of drop-down lists no longer sits against the edge.

Team and Enterprise organizations can open workspaces where on-site agents serve investigations without the data leaving the customer.

• Create workspaces (1 on Team, 20 on Enterprise) and choose which members may open each one.
• Enrol an agent on a host with a one-time code; it connects out only and runs only the tools its local policy allows.
• Memory forensics: list the memory dumps on a host, index one, then explore its processes, modules, memory map, handles, threads, tokens and environment, with leads such as injected code and hidden processes.
• Read process and physical memory in a hex view, and extract executable images from the dump.
• Every action is in the audit log, and usage is shown per workspace and per tool.

Windows executables are analysed with more computing power.

• Executable files get more processing capacity, so their reports finish sooner.

The file analysis report now opens with its conclusion: a verdict, the family, why, and what to block.

• Every report carries a verdict: malicious, suspicious, known good or no detection. Static analysis never calls a file clean, so no detection is never shown as green.
• Under the verdict: the malware family, the findings that led to it, and the key indicators to block.
• The capabilities found in the code are laid out as a MITRE ATT&CK matrix, by tactic.
• Every network indicator is listed with the tool that found it and its context, shown as text, with a pivot to its mlab.sh lookup and a button to add it to a case.
• Related samples: other files sharing a build fingerprint (imphash, authentihash, Rich header, PDB path), a command-and-control address or most of their bytes (TLSH), each with the reason.

Windows executables go through more tools, and malware configurations are extracted.

• Malware configurations of known families are decoded, with their command-and-control addresses and keys.
• Packers and protectors are identified, and obfuscated strings are recovered with FLOSS.
• Office files, PDFs, shortcuts, scripts and archives are routed to the right scanner, and more formats are accepted at upload.

A file report can be downloaded and explained, and nothing is generated unless you ask.

• Download the report as a PDF, or its results as JSON, from the top of the page.
• Ask for an AI explanation of what the file does. It is generated only when you click, needs an account, counts against your AI quota, and never changes the verdict.
• While a file is being analysed, the waiting page follows each tool live and estimates the time left.

Paid plans can keep a file report to their organization, and upload larger files.

• On Pro, Team and Enterprise, a file can be scanned privately: the report is visible to your organization only, and anyone else sees no trace of it.
• Upload up to 100 MB on paid plans, 10 MB on Free and without an account.
• A new upload panel: choose private or public, accept the terms when not signed in, and follow the upload as it happens.
• Daily file scans: 2 without an account, 10 on Free, 50 on Pro, 250 on Team, and fair use on Enterprise.

Files are now analysed in isolated sandboxes that hold no credentials, and samples are kept in the EU for a day at most.

• Each analysis runs in an isolated sandbox with its own single-use token, valid for that file only.
• Scanner images are rebuilt from pinned versions, and each build publishes its software bill of materials.
• Samples are stored privately in the EU and deleted after 24 hours.

Findings can now be filed as Jira tickets, and a verified IP network can be linked to a tracker just like a domain.

• Connect a Jira Cloud site with an account email and an API token; the token is stored encrypted and only ever sent to your atlassian.net site.
• Pick a GitHub repository or a Jira project from one searchable list, built for accounts with thousands of repositories.
• Tickets are closed and reopened through your Jira workflow's own transitions, so custom workflows keep working.
• An issue or ticket your team closes by hand stays closed while the finding is still there; it can reopen only if the finding goes away and comes back.
• Verified IP networks can be linked too: findings on their addresses and services open and close tickets.

Security monitoring now alerts on what it finds, by email and webhook, lets your team triage each finding, covers your verified IP networks, and has its own redesigned card.

• A new Monitoring tab in Organization settings explains what is watched and how, and lets the owner and admins pick which members are emailed when something is found.
• Each email lists every finding with where it was seen, how it was matched, its scores, the fixed versions and links to all its sources, and says plainly that a version match is something to verify, not a proven compromise.
• A finding is emailed once, and again only if it becomes exploited in the wild or more severe.
• Mark a finding as a false positive or an accepted risk right from the card: it moves to a Set aside list where it can be reopened, its ticket is closed, and it is not emailed again.
• Two new webhook events: a new finding on a monitored domain or network, and a finding that got worse (now exploited in the wild, or a higher severity).
• Monitoring findings open and close tickets in the linked GitHub repository or Jira project.
• The card on the domain page and on each verified asset now stands on its own: a verdict, hosts, software, open findings and what is exploited in the wild, with the hosts and the software inventory one click away.
• Long lists of fixed versions are shortened to the first few, with the full list on hover, and descriptions are no longer cut off.
• When nothing is found, the card says how much could actually be checked, and shows no green light when no software version was identified.
• Software found without a version, whose product is known to be exploited in the wild, is reported as an exposure to verify.
• Services found by your IP network scans are followed too; Linux distribution builds are never compared with upstream versions, so backported fixes no longer raise false alerts.

The Technologies section of the domain report now lists the known vulnerabilities of each identified version.

• Each technology shows its CVEs, the highest CVSS score and whether any is exploited in the wild, with a link to each CVE.
• WordPress plugins and themes are now matched by their slug against the advisories of the WordPress security vendors.
• More libraries are recognised by their exact npm package, and Progress MOVEit Transfer and Citrix NetScaler Gateway now come with their version.
• A technology without a version reads "Not checked", never "None".

RedKit's checks of exposed files and of vulnerable software were reworked so that what reaches your tickets is real.

• Exposed-file checks compare each answer with the site's answer to a random path: sites that answer everything with the same redirect or page no longer report critical files that do not exist.
• A forbidden (403) answer is no longer reported as a found file.
• Vulnerable software is now checked against the same vulnerability data as the rest of mlab.sh, including WordPress plugins and recent CVEs the NVD has not analysed yet.
• When that check cannot run, the report says so instead of reporting no vulnerabilities.

Link a scanned domain to a GitHub repository and RedKit keeps one issue per finding there: opened when a scan finds it, closed when it is fixed, reopened if it comes back.

• A new Alerting page under RedKit, Settings, next to History and the scheduled scans, gathers webhooks and issue trackers.
• Connect GitHub once by installing the mlab RedKit app on the account or organization you choose, with access to issues only.
• Linking a domain catches up on its past scans: the findings already known are filed right away.
• Marking a finding false positive or accepted risk closes its issue; removing the tag reopens it.
• A scan that ran only some modules never closes the findings of the others.
• Pick the lowest severity each repository receives, from Low to Critical; changing it closes or reopens issues to match.
• Issues are filed in private repositories by default. A public one needs an explicit confirmation, since anyone could read the findings.
• Jira is coming next.

A domain your organization verified is now followed continuously, with every subdomain under it: the software and versions each host runs, and the known vulnerabilities that affect them. Available on Team and Enterprise.

• The domain report of a verified domain shows a Security monitoring card under the RedKit recap, for members of the organization only.
• The same card sits in Organization, Infrastructure, on the detail of each verified domain: how many hosts and software are followed, and every open finding.
• Each finding names the host, the software and its version, the CVE with its CVSS score, whether it is exploited in the wild, and the version that fixes it when known.
• The first view of a domain that is not followed yet starts the monitoring; results show up within the hour.
• Only the current state is kept: a vulnerability that no longer applies, because the software was upgraded or removed, leaves the list by itself.
• Truncated version banners are never matched against vulnerabilities, so a vague version cannot raise a wave of false findings.

The domain report gains a Technologies section: the software, plugins and exact versions a site runs, identified on demand for the domain and the subdomains you pick. Available on Team and Enterprise.

• Each selected host is loaded once in a real browser, like a visitor would, and matched against more than 7,600 technology signatures.
• Exact versions where the site gives them away: CMS cores, WordPress plugins and themes, JavaScript libraries, web servers and languages.
• Every line says how it was found, and carries the identifier vulnerability tracking keys on (CPE, npm package or WordPress slug).
• Pick the domain and any of its subdomains, up to 10 per run. A run counts as one domain scan; hosts identified in the last 24 hours are shown without rerunning.
• Bot checks and unreachable sites are flagged as such instead of guessed at.
• Free and Pro accounts see the section locked, with what it would show.
• The pricing page lists it under Web Security, and previews Security Monitoring, coming to Team and Enterprise.

Every part of the domain scan report links to a free explainer on academy.mlab.sh: what the result means, why it matters and how to fix it.

• Each block of the report has a Learn link that opens the matching academy fiche, at the right section.
• Each finding in the list links to its fiche too, and the score panel links to a guide on reading the report.
• academy.mlab.sh adds a Secure your domain track: 12 fiches in English and French, written for the people who own the domain.
• Topics: SPF, DKIM and DMARC, HTTP security headers, TLS, certificates and CAA, known vulnerabilities, subdomain takeover, attack surface, third-party services and scripts, security.txt and the AI surface.
• The DNS and domain fiches gain sections on DNSSEC and on domain expiry.

inkdex, our code index and SAST engine, opens in beta: two binaries you run in CI/CD or on your machines, licensed and followed from RedKit, Code.

• inkdex indexes a repository as a whole: search, callers and callees, paths, routes and security facts.
• inkdex-vuln adds scan, with vulnerability findings and a dependency check against known advisories.
• One license per organization, on any number of machines and pipelines. It lists what the binaries may do and its limits.
• Runs keep working offline for up to 3 days, then sync once back online.
• The Inkdex tab shows your license, usage and every run, with CI tokens per pipeline and the downloads.
• Members create CI tokens; Owners and Admins rotate the license key.
• During the beta nothing is billed. Ask for a license from the Inkdex tab.

A connected Microsoft 365 / Entra ID tenant can now be scanned from RedKit, with a report against the CIS Microsoft 365 Foundations Benchmark v7.0.

• Launch a scan of any connected tenant from RedKit, Microsoft 365. One scan uses one RedKit credit.
• The first rules cover tenant-wide settings: app registration, tenant creation, user consent, the admin consent workflow, guest access and invitations, and app credential policies.
• The report lists each failing rule with the setting found and the value expected, the rules that pass, and the ones that could not be evaluated, with the reason.
• Microsoft Secure Score is shown next to it, overall and by category, for comparison.
• Each scan is compared with the previous one: new and fixed findings, and how findings and Secure Score move over time.
• Tenant scans appear in RedKit history with the other audits.
• This is a beta: more rules arrive with each version.

The domain scan now checks far more of a domain's surface, and the report reads every subdomain, not only the main site.

• DNSSEC is validated along the whole chain, not only detected.
• SPF and DMARC are evaluated the way receiving mail servers apply them, with spoofing protection rated as a whole.
• Every subdomain reachable on the web gets its own grade, with the known CVEs of the software it exposes.
• The AI and MCP surface of a domain is mapped, and security.txt is checked against the standard.
• Findings from every check are gathered in one list with an overall score, worst first.
• A report made by the earlier scanner says so and offers a new scan to fill in the missing checks.
• The full report is available from the API and the MCP integration; the previous format stays unchanged for existing integrations.

Organizations can now connect their Microsoft 365 / Entra ID tenant from the Infrastructure page. Tenant scans come next.

• A tenant administrator grants read-only consent to the mlab-scan app, in one step from Microsoft's own consent page.
• The tenant is tied to your organization when one of its verified domains is a domain you already proved on mlab.
• A tenant can only belong to one organization.
• Consent is checked daily, and the page shows when it has been revoked or a permission is missing.
• Owners and Admins can check a tenant on demand or disconnect it.
• Scans of a connected tenant are not running yet: connecting now gets you ready for them.

mlab.sh/engineering publishes long-form notes from the team: internal studies, benchmarks and the details behind how the platform is built.

• Every note starts with its method: data set, versions, hardware and how each number was measured.
• Notes show raw numbers and say where mlab does worse, not only where it wins.
• Charts are interactive, and each one can show the raw numbers behind it.
• Search the notes and filter them by tag; a filtered list keeps its own link, ready to share.
• The first note replays eleven public supply-chain attacks against postmortem and reads five large open-source projects by hand.

The URL lookup now weighs everything it knows into one score from 0 to 100, and shows the arithmetic behind it.

• Each URL gets a band (clean, suspect, high, critical) with every weighted reason listed, so you can see why.
• The domain's registration date is now checked live with its registry, even when the domain was never scanned.
• A brand-new domain behind a link now counts heavily in the score.
• When the registration date cannot be found, the page says the score rests on the URL alone instead of calling it clean.
• The same score is returned by the API, the MCP integration and exports.

A file report now opens on what the analysis found, worst first, before the raw output of each tool.

• YARA matches, remote templates, macros, packers, structural anomalies and high entropy are listed as findings, each with what it means.
• A file a reputation feed knows as malicious, or as known-good software, says so at the top.
• Identifiers like the imphash and PDB path are grouped apart, ready to pivot on.
• Files are now checked against a large, curated set of YARA rules.
• Many more checks now run on every file: what an executable can do (with its ATT&CK technique), DDE and Excel 4 macros, remote templates, active PDF content, shortcut command lines, encoded scripts, QR codes in images and phishing forms in HTML.
• When nothing was flagged, the report says it is an absence of signal, not a clean result.

The crypto lookup now shows why an address scores what it scores, and no longer calls an unknown address safe.

• Every reason behind the score is listed: which sanctions authority, which label.
• An address that is on none of our lists now reads Not enough data instead of a green 0.
• When the chain had to be guessed, the page says so next to the score.
• The API, the MCP integration and exports return the same score, with the same bands as email and URL lookups.

The SMS threat score has been removed. IOC extraction from text is unchanged and keeps every indicator it found.

• The IOC extraction API now returns the extracted indicators only: the risk and country parameters are gone.
• The smishing_risk tool is no longer available in the MCP integration.

Repository scanning now has its own home at code.mlab.sh, so it can grow at its own pace with more room for new scanners and integrations.

• Sign in to code.mlab.sh with your mlab.sh account: same organization, same members, same roles.
• GitHub and GitLab connections, scans, results, badges, exclusions and alerts all live on code.mlab.sh now.
• Your webhooks and activity log stay on mlab.sh.
• The Source code page in RedKit now points you to code.mlab.sh.

mlab.sh feels quicker everywhere, from the first page you open to the last report you read.

• Pages load fewer files, so they show up sooner.
• Faster navigation from one page to the next across the whole platform.

Tidier navigation and a lighter home page.

• Redkit now has its own link in the top bar.
• Every mlab platform sits in a single Platforms menu, grouped by governance, detection, attack surface and training.
• A new About page tells who builds mlab.sh and how we work.
• A lighter home page, with straight access to search and file analysis.

The search box on the home page dresses up for the right days of the year.

• Halloween, Christmas, New Year, Valentine's Day and Easter each bring a small animation.
• So do the days the security community celebrates: Data Privacy Day, Pi Day, April Fools', World Password Day and Sysadmin Day.
• Animations never get in the way of a search, and stay off if your device asks for reduced motion.

A new Settings tab on every repository page decides what its scans keep and when they reach you.

• Path exclusions: drop every result under paths like */tests/* or */fixtures/*, with * matching anything.
• Rule exclusions: drop an advisory or a rule you know does not apply, such as GHSA-xxxx or aws-access-key.
• Each scan says how many results your exclusions skipped, and links to them.
• Alerts: send a finished scan to your webhooks every time, or only when it finds something new at or above a severity you pick.

Findings you triaged keep their tags from one scan of a repository to the next.

• False positive, accepted risk and review later carry over to the same finding in the next scan, even when its line moved.
• An accepted risk is asked again when the finding climbs to high or critical. Fixed never carries over.
• New Review later tag on code scans and web audits, in the tag menu, the filters and bulk tagging.
• Code scan webhooks now list what is new since the previous scan.

Show in your README that a repository is scanned by mlab.sh.

• Off by default, turned on per repository, with the Markdown to copy.
• Shows the date of the latest scan, or an A to F grade if you choose. Never the findings themselves.
• Until you turn it on, the badge address reveals nothing about the repository.

Every source code scan now uses a RedKit credit, whatever started it.

• Scans on push, on connect and on a schedule count like the ones you launch by hand.
• Scan on push is now off by default, so a busy repository does not spend your credits on its own. Turn it on in the Automation tab.

Findings you tag as false positive or accepted risk now leave the score, and the result page gets the tools to work through a long report.

• False positives and accepted risks no longer count in the score, the posture dashboard, comparisons, the PDF or the recap email.
• Filter findings by tag, hide dismissed ones, tag a selection in one go, and export what you see as CSV or JSON.
• Run again, schedule, cancel or delete an audit from its pages.

Every RedKit list is easier to read and to act on.

• History: filters by type (code scans included), status and date, the grade of each audit, and a one-click comparison with the previous one.
• Posture dashboard: score trend since the last audit, a marker on stale audits, and the verified domains never audited.
• Scheduled scans: edit a schedule, run it now, and open its latest result.
• Source code: last scan per repository, and filters, tags and export on findings.

Your past lookups are paged, searchable and one click away from a case.

• Scan history and bookmarks: real paging, type filters, copy, bookmark and add a selection to a case.
• IP results show when they were fetched, with a re-check once a day.
• Reverse DNS names and resolved addresses on IP pages open their own lookup.
• Pasting several indicators into search offers to triage them in batch.
• Batch triage: filters, CSV export, file part of the results into a case, and look up every unknown indicator in one go.

Adding indicators to a case works the same way everywhere, with a search across your cases.

• Search your cases, open ones first, or start a new one without leaving the page.
• Case list: search, status filter and sorting. Case page: filter and search indicators, copy them, and see what mlab already knows about each.

More control over what your organization runs.

• API keys: rotate or rename a key, and see when and by whom it was created.
• Webhooks: change the URL or format, rotate the signing key, filter deliveries, replay every dead delivery at once, and copy a delivery ID.
• Audit log: filter by member and target, with paging and links to what changed.
• Team: search, filter by role and see when each member was last active.
• Infrastructure: filters, re-check every pending domain at once, and open an asset's lookup.
• Usage shows your plan's limits next to what you used.

Pasting defanged text into IOC extraction now returns the real indicators, instead of missing them or returning a wrong one.

• hxxp:// and hxxps:// links are recognised as URLs.
• A link written with [.] comes back whole: http://evil[.]example[.]net/x used to come back as http://evil, and is now http://evil.example.net/x.
• Addresses written with [at], hosts written with (.) or [dot] and ports written with [:] are read too.
• Indicators exported defanged from mlab.sh read back as themselves when pasted into the extractor.
• Applies everywhere indicators are pulled from text: the API, the text scan, shell script analysis and the AI assistant tools.

Connect a GitLab group or your personal namespace: every project you maintain in it is proven at once, private ones included, and can be scanned like a GitHub repository.

• GitLab (Cloud) connects a GitLab.com group or namespace in one round trip: authorize mlab.sh, pick what to connect, done.
• GitLab (Self-Managed) connects your own GitLab instance through an application you create on it, with a step-by-step guide and a check of your application before anything is saved.
• A project is proven when the person who connects it is a Maintainer or Owner on it; if they lose that role, the project loses its proof at the next sync.
• Repository pages show GitLab projects like GitHub ones: an Overview (description, languages, size, visibility), an Activity tab (commits per week, latest commits with their signature, contributors, releases) and a Hygiene tab.
• GitLab hygiene checks the protected default branch, required approvals, force-push protection, pipelines that must pass before a merge, signed commits, leaked-credential detection in CI, a security policy, code owners, automated dependency updates and committed credential files.
• Source code scans run on GitLab projects too: by hand, when a project is first connected, on a schedule, and after each push to the default branch.
• New projects show up on their own every day, or at once with Resync; nested groups are supported.
• mlab.sh only reads: nothing is installed in your projects and nothing is written to them.

Everything you connected, in one place, and a catalog to connect more.

• Infrastructure, then Integrations, lists every connected GitHub account and GitLab namespace with its repositories, who connected it and when.
• Each account can be resynced, opened on GitHub or GitLab, or disconnected from the same card.
• Disconnecting can also remove its repositories from your infrastructure; repositories that were already scanned are always kept, so their scan history stays.
• A connection that lost its access (the app was revoked, or its owner lost their role) says so and offers to reconnect, keeping its repositories and their history.
• When an integration stays unreachable for a week, its repositories that were never scanned are removed; scanned ones are kept.
• The catalog lists what you can connect, with search and filters, and a link to ask for an integration we do not offer yet.

Scan your GitHub repositories for leaked credentials, vulnerable dependencies, supply-chain risks and unsafe GitHub Actions.

• Launch a scan from a repository's page: a quick scan checks the default branch in a few minutes, a full scan also reads every branch and the whole git history.
• Leaked credentials are found in the code and in the history: one deleted from the code but still in an old commit is flagged so you know to rotate it.
• Dependencies from your lockfiles are checked against known vulnerabilities, with the version that fixes each one.
• Install-time scripts, obfuscated code and risky build files are flagged, as well as GitHub Actions workflows open to injection or using unpinned actions.
• Each finding links to the exact file and line on GitHub, at the commit that was scanned.
• A new Automation tab sets when a repository is scanned: on every push to the default branch, when it is first connected, and on a daily, weekly or monthly schedule.
• Repositories connected through the GitHub App can be scanned automatically; repositories proven by a .mlab file are scanned by hand.
• Every scan is kept in the repository's history with its status and finding counts by severity.
• Two new webhook events tell your tools when a code scan completes or fails.

Scan the IP ranges you own for open ports and services, and watch how they change over time.

• Launch a scan on a validated IP range from Run Audit: it discovers open ports and identifies the service and version behind each one.
• Two profiles: a quick scan of the most common ports in minutes, and a deep scan of all 65535 ports for an exhaustive sweep.
• My IP lists every host across all your ranges and scans, with a search box and filters by protocol and by range (a searchable multi-select).
• Each host has an evolution view: open ports over time, when each port was first and last seen, and what opened or closed since the previous scan.
• IP scans now appear in your RedKit history and on the dashboard, alongside domain audits, with a clear per-run status.
• Schedule a range scan to run weekly or monthly, choosing the quick or deep profile, like a domain audit.
• A range is only scannable once it is validated, so you only ever scan what you own.

Cross-reference every service version found on your ranges against known CVEs, in one click.

• "Check for vulnerabilities" on My IP matches every detected product and version against known CVEs.
• Results list each CVE with its severity, CVSS and EPSS scores, whether it is known-exploited (KEV), and the exact hosts that expose it.
• Findings are ordered worst-first: known-exploited and highest-scoring issues at the top.
• Each host's detail page shows the CVEs affecting it, and hosts in the report link straight to their page.
• Every check is kept, so the latest report is shown when you open My IP and your exposure over time is on record.

Each API key now does only what you allow it to, chosen with checkboxes when you create it.

• Choose a key's permissions when you create it: IOC lookups, domain scans, file and script analysis, batch triage, RedKit audits, scheduled scans, cases and finding tags, each in read or write.
• Owners and admins can change a key's permissions at any time; the change applies from its next call.
• Keys created before this release keep full access, so your integrations keep working unchanged.
• A call outside a key's permissions is refused with a message naming the missing permission.
• Keys can now work on cases, finding tags, scheduled scans, RedKit audits, batch triage and the AI script analysis.
• Whatever its permissions, a key never manages members, settings, other keys or anyone's account.
• Every permission change is written to the audit log.

Keys are shared by the organization and say what each of them did.

• API keys now live in the organization settings, where every member can see them and owners and admins manage them.
• Each key shows its scans this month and when it was last used.
• Scans made with a key are counted per key and named after it in the team activity feed, instead of being credited to a person.
• Cases, comments and finding tags written with a key are signed with the key's name.
• Team and Enterprise plans get up to 100 API keys, and 100 MCP tokens per member.
• Files uploaded with an "Authorization: Bearer" key are now credited to the organization, like the "token" form.

Team and Enterprise organizations can follow what they consumed, month by month, since they were created.

• A usage page with a month, a year and a since-creation view, charts by day, month and type, and tables month by month and year by year.
• Monthly counts are kept for as long as the organization exists, even after the detailed history expires.
• A breakdown by API key shows what each integration consumed.
• Export the whole history as CSV.
• Open it from the dashboard or from the team activity page.

The organization's settings now have their own page, with tabs.

• Organization, Webhooks and API keys tabs, with an overview of the organization.
• Members and viewers can now read the settings; owners and admins change them.
• Webhook addresses and API keys stay hidden from those who cannot manage them.

Declare more of what your organization operates, and prove it is yours.

• IP networks: one public address or a range up to /16 (IPv4) or /32 (IPv6), validated by the mlab.sh team once you have shown you own or operate it.
• Code repositories: public GitHub and GitLab repositories, proven with a .mlab file holding a VERIF_CODE line.
• Amazon S3 buckets: proven with a .mlab object readable by anyone, in every region.
• The .mlab file can hold lines for other tools; only VERIF_CODE is read.
• When a check fails, the message says why: not public, file missing, wrong code, unknown bucket.
• The infrastructure pages were redesigned: counters, a clear status for each asset, and the proof to add on each asset's page.

Once your company domain is verified, colleagues who sign up with an address on it can land straight in your organization.

• Turn on joining by email domain from your organization settings, or while setting up the organization. It is off by default.
• Colleagues who sign up with an address on your verified domain join your organization as Members, no invitation needed.
• They join only after proving they own the address: a code sent by email, or signing in with Google or GitHub.
• When joining is off, sign-ups on your domain are refused with a message to ask your admins for an invitation, instead of creating a second organization.
• Available on the Team and Enterprise plans.
• Each company domain belongs to one organization. Verifying it settles any other organization's unverified claim.
• The dashboard reminds admins when the organization's domain is not verified yet.

Domain reports no longer claim a domain has no SSL certificate when it does.

• Reports older than a day showed "No SSL certificate found" because their certificates had expired from our records. They are now kept for 90 days.
• A report whose certificates are missing fetches them again the next time it is opened, no rescan needed.
• A domain with no certificate in Certificate Transparency logs now says so, with the date it was checked.
• When certificates cannot be loaded for a moment, the report says so and offers a reload instead of reporting none.

Every way to use mlab.sh outside the website, on one page.

• MCP for AI assistants and Claude Code plugins, VS Code and JetBrains extensions, a GitHub Action, an n8n node, a Chrome and Firefox extension and the mlab CLI.
• Read-only audits of cloud accounts, Proxmox VE, UniFi and MikroTik, plus our open-source security scanners.
• Each entry links straight to its store listing and to its source code.

The long pages of the site now share the layout of a domain report.

• A navigation rail that follows you down the page and highlights where you are.
• Tools grouped by category, with search.
• Glossary sorted from A to Z, with a direct link to every term.
• Cheat sheets split into sections, such as HTTP status codes by class or ports by service.
• Terms of service, privacy policy and terms of sale with a link to every article.
• The changelog now lists releases by version.

Result pages answer faster, even under load.

• Domain, IP and hash pages load faster, and stay fast when many people use mlab at once.
• File lookups by MD5 or SHA-1 answer faster.
• Pasted lists of indicators are triaged several at a time.

Decide who in your organization can do what.

• Four roles: Owner, Admin, Member and Viewer.
• Viewers can read everything but cannot run scans or change anything.
• Admins manage members, API keys, webhooks and integrations; only the owner manages billing.
• Change a member's role, remove a member, or transfer ownership from the team page.

See every browser signed in to your account and sign out the ones you do not recognise.

• Stay signed in on several devices at once.
• Each session shows its browser, IP address and last activity.
• Sign out a single session, or every session except the one you are using.
• Changing your password now signs out all your other sessions.

A record of who changed what in your organization.

• Member invitations, API keys, MCP tokens, 2FA changes, webhooks, infrastructure and billing events in one timeline.
• Filter by category and period, and export to CSV.
• History of 7 days on Free, 30 days on Pro, 60 days on Team and Enterprise.

One place for everything you and your team looked up.

• Switch the dashboard between your own activity and your organization's.
• A single scan history across every lookup type, with filters.
• Team subscriptions show which member manages billing.

Download domain and RedKit results as ready-to-share PDF reports.

• Same findings and score as the result page, laid out for reading and printing.
• Consistent output whatever your browser or theme.

See what your organization investigated, and who looked.

• A feed of every lookup across the team, with the member on each line.
• The indicators your team reached for most, and how many people looked at each.
• Tells a paid scan apart from a result page that was only viewed.

Push mlab events to your own tools.

• Native formats for Slack, Discord and Microsoft Teams, plus a signed generic JSON format.
• Choose which events each endpoint receives.
• Automatic retries, a delivery log and one-click replay of failed deliveries.

Group the indicators of an investigation and discuss them with your team.

• Add indicators to a case from any lookup page, or paste a list.
• Comment on the case or on a single indicator.
• Open and close cases as the investigation moves.

Know when a domain or an IP changes.

• Domain and IP pages show what changed since the previous lookup.
• Schedule recurring scans of any domain, including look-alikes of your brand and your suppliers.
• Get an email or a webhook when a scheduled scan finds changes.

Take any lookup result into your tickets, spreadsheets and threat platforms.

• Export as JSON, CSV, STIX 2.1 or MISP from every lookup page.
• Indicators are defanged where it matters, so they are safe to paste.

Two lookups rebuilt to answer on the first try.

• Crypto address lookup with detection of the chain and the address format.
• Live email posture for any domain: MX, SPF, DMARC and DKIM.
• Improved IP and URL analysis.