Carsensor and C-MATCH Breach: 3.7M Records, Nissan and Mitsubishi Sites

On 21 October 2026 Recruit said unauthorized access to its Carsensor used-car marketplace and its C-MATCH dealer software may have leaked up to 3,709,551 personal-information records. Nissan and Mitsubishi Motors paused official used-car search sites that run on Recruit's system. Affected users should expect targeted scams; dealers should treat their login IDs as exposed.

Recruit Co., Ltd. runs Carsensor (カーセンサー), one of Japan's largest used-car listing services, on the web and as an app. It also runs C-MATCH, a business-support service that used-car dealers use to register and update the vehicles they list. Recruit detected suspicious external access on Saturday 17 October, shut every Carsensor-related service from about 17:00 JST, and published its findings four days later.

The headline number is large, but two smaller details matter more for anyone who builds or buys a platform. First, up to 447,670 consumer records may include a full street address down to building and room number, not just the city or ward. Second, the same Recruit system also runs the official used-car search sites of two carmakers. One intrusion at one provider took three brands' used-car search offline, and as of the evening of 24 October the two carmaker sites were still showing suspension notices even though Carsensor itself had started coming back on 22 October.

This post is built from Recruit's own press release and service notice and from the notices Nissan and Mitsubishi Motors posted on their own used-car sites. Where we rely on news reports, we say so. Recruit has not named a vulnerability, a product, an attacker or an entry point. It describes the cause only as unauthorized access by a third party, and we do not guess beyond that.

What happened

According to Recruit's 21 October press release, suspicious external access to Carsensor-related systems was detected on Saturday 17 October 2026. To protect customers and business partners and to check the impact, Recruit suspended all Carsensor-related services from about 17:00 that day: the Carsensor website, the Carsensor app, C-MATCH and other connected services. On Tuesday 20 October its investigation identified which personal data items may have leaked and the maximum count for each. On Wednesday 21 October it published the press release (with a PDF version), opened an inquiry page and said it had already filed a preliminary report with Japan's Personal Information Protection Commission (PPC).

Recruit's service notice on the Carsensor home page, updated 22 October, adds the next step: services began coming back from about 13:00 JST on Thursday 22 October, "starting with services and functions whose safety could be confirmed," in our translation. The notice warns that C-MATCH was also stopped during the outage, so stock and price changes dealers made in that period may not yet be reflected in listings, and that replies to inquiries sent before the outage may be delayed.

Meanwhile, two carmakers posted their own notices. Nissan's official used-car search site (日産公式中古車検索サイト) and Mitsubishi Motors' M・C Net (M・Cネット) used-car service both say that suspicious external access was detected on 17 October at Recruit's system, which Nissan says it uses to run the service and which Mitsubishi says it has outsourced the service's operation to. Both say they suspended their service from about 17:00 on 17 October for the safety of customers and business partners and to check the impact, that Recruit is investigating cause and scope, and that they will announce a restart when one is in sight.

Kyodo News and TBS/JNN reported the carmaker suspensions on 21 October. Both also reported that Mazda had stopped updating vehicle information on its official used-car search site because it uses Recruit's service, and TBS added that cars already sold might still be shown there. We did not retrieve a Mazda notice ourselves, so the Mazda detail here rests on those reports.

Timeline

All times are Japan Standard Time and appear only where a source gives one.

The Last-Modified times describe when each notice page was last changed on the server. They are not a statement by either company about when they learned of the incident, and we do not read anything more into them.

What is still unknown

• The entry point. Recruit says "unauthorized access by a third party" and nothing else. No vulnerability, product, credential or supplier is named. No CVE has been linked to this incident.
• Whether data actually left. Recruit's wording throughout is that information "may have leaked" (漏えいした可能性). The counts are maximums. Recruit has not said it confirmed exfiltration.
• Whether the carmaker sites' own users are inside the count. Nissan's and Mitsubishi's notices talk only about suspending their services. Neither says whether people who used those sites are among the 3,709,551 records, or are a separate population.
• Extortion. We have seen no claim of ransomware or a ransom demand, and Recruit mentions neither.
• When the carmaker sites come back. Neither notice gives a date.
• Who did it. Nobody has attributed the access.

The numbers, read carefully

Recruit gives one total, up to 3,709,551 records, split into four groups. These are records, not people. One person who sent inquiries about several cars, or who both sent an inquiry and posted a review, may appear more than once, and Recruit has not published a count of unique individuals.

All four groups also include an internal management ID that Recruit assigns. Recruit says none of the four groups includes payment data such as credit card details, and none includes login passwords.

Inquiry senders: the biggest group

The arithmetic checks: the three subsets sum to 3,210,421, and the four groups sum to 3,709,551.

The 447,670 full addresses

Recruit adds a note that changes how the first group should be read. The "address" in group (1) is, as a rule, only the municipality: city, ward, town or village. But up to 447,670 records may contain a full address including the block, lot number, building name and room number. That is roughly one in seven of the inquiry records.

A city-level location attached to a name is a weak identifier on its own. A full address with a room number, attached to a name and in some cases to the fact that the person was shopping for a used car, is enough to send convincing post or to turn up at the door. This subset is the one that most changes the risk for consumers, and it is the one most headlines skipped.

Dealer records: small count, higher value

Group (3) is smaller, 483,168 records, but richer per record. A dealer record pairs a contact name and phone number with a secondhand dealer licence number (古物商許可番号), the licence holder's name and the issuing prefecture, plus the dealer's C-MATCH login ID. For sole proprietors, who often use personal details for the business, it can also include an address, phone, fax and debit account information.

Recruit says passwords were not included. That still leaves half of a credential pair, and a set of business identifiers that are normally only shared between a dealer and the platform. An email or call that quotes a dealer's licence number and login ID will sound like it comes from the platform.

Technical details

Recruit has published no technical indicators. There is no CVE, no product name, no IP address, domain, file hash or user agent in any Recruit, Nissan or Mitsubishi notice we read. What follows is every concrete, checkable detail the primary sources do give, plus what we observed on the affected hosts. Treat anything not in this section as unknown.

Affected services as named by Recruit

Recruit's press release names only Carsensor net (including the app) and C-MATCH as the "target services" for the data leak.

Data elements, field by field

Pulled from the press release and PDF, translated:

• Identity: name (all groups).
• Location: address (group 1, normally municipality only; up to 447,670 with full street, building and room); office or counter address and postcode (group 3, sole proprietors).
• Contact: phone, fax, email (group 1 subset of 799); email (group 2 subset of 4; group 4); phone (group 3, all; fax for sole proprietors).
• Behavioural: inquiry content, age band, gender (group 1 subsets).
• Regulatory: secondhand dealer licence number, licence holder name, issuing prefecture (group 3).
• Account: login ID (groups 3 and 4).
• Financial: debit account information (group 3, sole proprietors only).
• Internal: a Recruit-assigned management ID (all groups).
• Explicitly not included: payment data such as credit cards, and login passwords (all groups).

Containment and restoration, as described

• Shutdown scope. Every Carsensor-related service, not just the affected component. That included the dealer-facing C-MATCH, which is how listings get updated, so the whole marketplace froze.
• Restart method. A phased restart from about 13:00 on 22 October, bringing back services and functions whose safety had been confirmed first. Recruit has not listed which functions returned first or which, if any, remain off.
• Data freshness warning. Recruit tells buyers to confirm stock and price directly with the dealer before visiting or signing, because changes during the stop may not be reflected.

What we saw on the affected hosts (24 October, about 14:30 GMT)

Both carmaker hosts serve a static page from an Apache server with a 503 status rather than a 200 page or a redirect. A 503 tells browsers and crawlers that the outage is temporary. That is a small but correct operational choice, and one worth copying: it keeps a maintenance page from being indexed as the site's real content.

Official contacts

• Recruit's dedicated inquiry page for this incident: recruit-help.jp, article 100004204 (linked in Sources). The page is a JavaScript application; it did not render without a browser when we fetched it, so we cannot describe its contents.
• Recruit says it is contacting affected people individually and, for those it cannot reach (unreachable contact details, former employees), is using the press release and the inquiry desk instead.

Regulatory filing

Recruit says it has already filed a preliminary report (速報) with the PPC. Under the PPC's published guidance, a leak or possible leak caused by conduct with an unauthorized purpose, which includes outside attackers, is a reportable case. The PPC asks businesses to report promptly after discovery and, for that category, sets a 60-day deadline from discovery for the full report. If Recruit treats 17 October as the discovery date, that would put the final report in mid December. Recruit has not said when it will publish more.

What there is not

No IOCs, no hashes, no vulnerability identifiers, no attacker infrastructure and no exploitation details have been published by Recruit, Nissan or Mitsubishi. If you see a list of indicators attributed to this incident, check where it came from before you load it into a blocklist.

Why one intrusion took three brands offline

Most people who use a carmaker's "official used-car search" never think about who runs it. In this case, the carmakers' own notices say it plainly. Nissan says it uses Recruit's system to run its official used-car search site. Mitsubishi Motors says it outsources the operation of M・C Net to Recruit. Kyodo and TBS report that Mazda's used-car site depends on a Recruit service too, which is why its listings stopped updating.

This is a common shape. A marketplace builds a listing engine, a dealer management tool and a search front end. It then offers the same stack, under another brand's name and domain, to manufacturers who want an official used-car site without running one. The brand owns the domain and the customer relationship. The platform owns the code, the database and the operations.

When the platform pulls the plug to contain an intrusion, every brand on it goes dark at once, whether or not that brand's own data was touched. That is the right call for containment, and it is also why a brand needs to plan for it before it happens.

Three practical consequences follow from the notices:

1. The carmakers learned about the problem from their provider. Both notices describe detection "at Recruit's system." The carmakers could not see the access themselves; they could only act on what Recruit told them.
2. The carmakers' restart depends on the provider's investigation. Both say Recruit is investigating and that they will announce a restart when one is in sight. Carsensor began restarting on 22 October; the carmaker sites were still dark two days later. We do not know why, and neither company has said. It may reflect the carmakers' own checks, a different restart order on Recruit's side or something else entirely.
3. The carmakers cannot yet tell their own customers whether they are affected. Neither notice says whether the brand's own site users are among the records Recruit counted. Both promise to share facts that need sharing as the investigation progresses.

A market signal, not just a security one

A market news item published at 14:11 JST on Monday 19 October said shares of used-car retailer Nextage fell sharply on concern that the Carsensor suspension would slow sales, and that other used-car stocks also softened. That was two days before Recruit's press release. A listing marketplace is a sales channel. When it stops, dealers lose leads, and investors notice.

Who is affected

Recruit says that as of 21 October it had not confirmed any secondary damage from the incident.

What to do now

If you used Carsensor or a carmaker's used-car site

Recruit's own advice is short: do not open, reply to or answer suspicious mail, SMS, post or calls; do not open links in them; and do not open attachments. Put concretely:

1. Expect messages that know about your car search. A scammer with your name, area and the fact that you asked a dealer about a car can write something that sounds right. Treat any message about "your inquiry," a "refund," a "reservation fee" or a "car you looked at" as suspect until you have confirmed it by calling the dealer on a number you found yourself.
2. Never pay a deposit through a link in a message. Confirm stock, price and payment details with the dealer directly, which is also what Recruit asks buyers to do because listings may be out of date.
3. Watch the post. If your full address may be in the data, be wary of letters that ask you to call a number, scan a QR code or return a form.
4. Use Recruit's inquiry page to ask whether you are affected. Recruit says it is contacting people individually.

If you are a dealer on C-MATCH

1. Change your C-MATCH password once Recruit's guidance allows, and anywhere else you reused it. Recruit says passwords were not taken, but your login ID was, and many dealers reuse passwords across portals.
2. Turn on any extra login protection the platform offers, and on every other dealer portal you use.
3. Treat calls and emails that quote your licence number or login ID as unverified. Those details used to be a sign of a real platform contact. They no longer are.
4. Sole proprietors: watch your debit account. Your debit account information may be in the data. Watch statements for unfamiliar debits and be suspicious of any request to "update" bank details, from anyone.
5. Brief your staff. Whoever answers the phone at the dealership is the most likely target.

If you are Recruit staff, a contractor or sales-agency staff

1. Expect spear phishing that uses your name, work email and login ID and pretends to come from IT or from the Carsensor team.
2. Report rather than reply to any unexpected password reset, MFA prompt or "account check."

If you run a brand site on someone else's platform

This is the larger audience for this post: any company whose customer-facing site, portal or app is run by a partner. The steps below are generic and use placeholders such as shop.example.jp; substitute your own hostnames.

Step 1: List every customer-facing hostname you own and who serves it.

# Who answers for this hostname? A CNAME to a partner's domain is a strong hint.
dig +short CNAME shop.example.jp
dig +short A shop.example.jp

# What does the server say about itself?
curl -sI https://shop.example.jp/ | grep -iE '^(server|via|x-powered-by|last-modified|retry-after):'

Step 2: Check which other names share the certificate. A shared certificate often means shared infrastructure.

openssl s_client -connect shop.example.jp:443 -servername shop.example.jp </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -ext subjectAltName

If the subject alternative names list other brands, or the partner's own domains, you are on a shared stack. Write that down in your vendor inventory.

Step 3: Find out what customer data the partner holds for you. Ask the partner for a field-level data map. If you have read access to a reporting database or a data export, inventory personal-data columns yourself:

-- PostgreSQL: find columns that probably hold personal data
SELECT table_schema, table_name, column_name
FROM information_schema.columns
WHERE column_name ILIKE ANY (ARRAY[
  '%name%', '%addr%', '%postal%', '%zip%', '%phone%', '%tel%', '%fax%',
  '%mail%', '%login%', '%bank%', '%account%', '%license%', '%licence%'
])
ORDER BY 1, 2, 3;

Look specifically for free-text address fields. Recruit's note that most addresses were city level, but up to 447,670 were full, suggests a single address field that people sometimes fill in completely. Free text defeats any policy that says "we only keep the city."

Step 4: Prepare a correct maintenance page now. Both carmaker hosts served a 503 with a plain notice, which is the right pattern. Have yours ready on infrastructure you control, not on the partner's.

# Static maintenance page served by your own edge, independent of the partner
server {
    listen 443 ssl;
    server_name shop.example.jp;
    # ssl_certificate and ssl_certificate_key as usual
    location / {
        return 503;
    }
    error_page 503 @maintenance;
    location @maintenance {
        add_header Retry-After 3600 always;
        root /var/www/maintenance;
        rewrite ^ /index.html break;
    }
}

Step 5: Watch logins for known IDs. If login IDs for your users or staff may be exposed anywhere, alert on failed logins per ID rather than only per IP address. Attackers who already know valid IDs spread attempts across many addresses. With JSON application logs:

# Count failed logins per login ID in the last log file, highest first
jq -r 'select(.event=="login_failed") | .login_id' app.log \
  | sort | uniq -c | sort -rn | head -20

Step 6: Check that your notification mail will be trusted, and spoofed mail will not. Breach notices are a gift to phishers, who copy their wording. Make sure your sending domain publishes SPF, DKIM and an enforcing DMARC policy.

dig +short TXT example.jp | grep -i spf
dig +short TXT _dmarc.example.jp

A DMARC record with p=reject or p=quarantine makes it harder for someone to send mail that looks like it came from your domain.

Step 7: Rehearse the "provider pulled the plug" scenario. Decide in advance who in your company approves the maintenance notice, who talks to customers, who talks to the regulator, and what you will say when your provider cannot yet tell you whether your users are affected. Both carmakers had to publish exactly that kind of notice.

What changed since the first reports

• From "suspended" to "may have leaked." The first public signal was a service suspension, visible enough by 19 October to move used-car stocks. Recruit's 21 October release added the data categories and the maximum count.
• Carsensor is back, the carmaker sites are not. Recruit's notice says the phased restart began around 13:00 on 22 October. On the evening of 24 October, Carsensor's home page was serving normal listings, while the Nissan and Mitsubishi used-car hosts still returned HTTP 503 with their original notices.
• The Mazda effect. Early reports focused on Nissan and Mitsubishi. TBS/JNN and a second Kyodo item added that Mazda's used-car listings had stopped updating.
• Press counts round differently. Kyodo reported "about 3.7 million," TBS "about 3.71 million." Recruit's exact figure is 3,709,551, and it is a maximum count of records.

Open questions

1. How did the attacker get in, and was it through Carsensor's public-facing systems, C-MATCH, an internal tool, a supplier or credentials?
2. Did data definitely leave, or is "may have leaked" a precaution because access to the stores cannot be ruled out?
3. Are users of the Nissan, Mitsubishi and Mazda used-car sites inside the 3,709,551 records, or a separate group? Do those brands' customer records sit in the same database as Carsensor's?
4. Has Recruit forced password resets or added login protection for C-MATCH dealers and for staff whose login IDs were exposed?
5. Why did the carmaker sites stay offline after Carsensor's phased restart began?
6. How many unique individuals do the 3,709,551 records represent?
7. When will Recruit publish the results of its investigation, and will the PPC publish anything?

What would have helped

None of this is a judgement on Recruit or on the carmakers. Recruit cut every related service the day it detected suspicious access, scoped the data in three days, reported to the regulator and began a careful restart in five. Nissan and Mitsubishi put up clear, honest notices with correct HTTP status codes and did not overstate what they knew. The useful question for everyone else is how to make the same class of event smaller and easier to explain.

Practices any team can use

• Map shared fate before it bites. For every customer-facing site, record who runs it, what data it holds and which other brands share the stack. If a partner's single shutdown switch turns off your site, you should know that from the contract, not from your customers.
• Contract for notification timing and content. Write into the agreement how fast the provider must tell you, what it must tell you (scope, data items, whether your users are in it) and how often it will update you. A brand that cannot say whether its own customers are affected is in a hard spot.
• Segregate tenants' data, and prove it. If a platform runs sites for several brands, each brand's customer data should live in a separate schema, database or encryption context, with access paths that cannot cross. Ask for evidence, such as a test that one tenant's service account cannot read another's rows.
• Minimise free-text personal fields. If you only need a prefecture or city to route an inquiry, use a structured field that cannot hold a room number. Purge full addresses once they have served their purpose.
• Treat login IDs as semi-secret. Recruit's dealer and staff records include login IDs. Wherever possible, use login identifiers that are not printed on business cards, and add a second factor so that a known ID is not half the work of an account takeover.
• Keep bank details out of operational stores. Debit account information for sole-proprietor dealers sits in the same breach as their contact names. Payment details are better kept in a separate system with its own access controls, referenced by token.
• Shut down wide, restart narrow. Recruit stopped everything and restarted function by function. That is the right order. Plan your restart sequence before you need it, so you are not designing it during the incident.
• Shorten the patch clock for internet-facing services. Whatever the entry point turns out to be, every web platform is built from frameworks, libraries and base images that need fast patching. Inventory them and rebuild quickly when a fix ships.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists, in two modes: an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, and it covers seven package ecosystems. Gold Open Source (gold.safeguard.sh, free, no login) is searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, with a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) supplies hardened drop-in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge if it regresses.

To be plain about the limits: Recruit has not said how the attacker got in, so nobody outside the investigation can say whether a software vulnerability was involved at all, let alone one in an open source package. Safeguard has no advisory related to this incident and no patched build of anything connected to it. Where these capabilities help is the layer every web platform shares: the libraries, frameworks and container images its services are built from. Pulling patched, signed components from a curated source and rebuilding fast when an advisory lands removes one common way in. It does nothing about tenant segregation, data minimisation, login protection or vendor contracts, which are the lessons that matter most here.

Where Safeguard fits

Honest scope first: Safeguard would not have prevented this incident. It would not have kept the carmaker sites online, and it does not decide how a platform segregates its tenants' data. Those are architecture, contract and operations questions.

What Safeguard does cover, at GA:

• Dependency and image scanning of the repositories, container images and SBOM files behind a web platform or a white-label site, with JSON results under ./output.
• Component search across projects: the platform shows which projects contain a given component and version, so when an advisory lands for a framework that your listing engine or dealer portal uses, you can see every place it ships, including the services you run for other brands.
• Vulnerability matching and reachability analysis, to rank the vulnerable code paths your application actually calls first.
• Policies and gates evaluated in the platform, so a build of an internet-facing service with a known exploited vulnerability can be blocked or held for approval.
• Autonomous remediation with tested fix pull requests, which ships off by default.
• The Safeguard CLI assistant, which can edit code and configuration and run commands only with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You could ask it to add a tenant isolation test to your platform's test suite, or to replace a free-text address field with structured prefecture and city fields plus a migration, and approve each change as it is made.

safeguard scan --dir .                 # a repository
safeguard scan --image <name>          # a container image
safeguard scan --sbom <file>           # an SBOM file

For a brand that does not run the code itself, the useful step is to ask the provider for an SBOM of the service that carries your name and scan it with safeguard scan --sbom. That tells you what is inside the stack you depend on, even if you cannot patch it yourself.

Where Safeguard does not help: it does not monitor production traffic, logins or egress; it does not detect intrusions; it does not manage passwords, multi-factor authentication or tenant data segregation; and it cannot see inside a provider's hosted service unless the provider shares an SBOM or the code.

Common mistakes and troubleshooting

• Reading 3.7 million as 3.7 million people. It is a maximum count of records across four groups. Duplicates are likely. Use it as an upper bound, not a headcount.
• Ignoring the small subsets. The 447,670 full addresses and the dealer debit details carry more risk per record than the city-level majority.
• Assuming "no passwords" means "no account risk." Login IDs were exposed for dealers and staff. A known ID halves the work of a guessing attack, and password reuse does the rest.
• Assuming your brand is safe because your domain was not named. Nissan and Mitsubishi were not named in Recruit's release. Their sites went dark anyway because they run on the same system.
• Treating a partner-run site as somebody else's problem. Customers do not read the footer. They will call the brand, and the regulator may too.
• Building the maintenance page on the partner's infrastructure. If the partner is down, your notice may be down with it. Host it at your own edge.
• Loading unverified "IOC lists." No primary source has published indicators for this incident. Check any list's origin first.
• Linking this to other Japanese breaches this month. October 2026 has brought several Japanese platform breaches. Nothing we have read links this one to any of them; shared timing is not a shared cause.

FAQ

What happened at Carsensor?

Recruit detected suspicious external access to Carsensor-related systems on 17 October 2026 and suspended all related services from about 17:00 JST. On 21 October it said personal information may have leaked from Carsensor net (including the app) and C-MATCH, up to 3,709,551 records.

How many people are affected?

Recruit has not said. It gives a maximum of 3,709,551 records across four groups: inquiry senders, review posters, C-MATCH dealers, and Recruit staff, contractors and sales-agency staff. One person can appear in more than one record.

Was my full address leaked?

Possibly. Recruit says the address in inquiry records is normally only the city, ward, town or village, but up to 447,670 records may include a full address with block, building and room number. Recruit says it is contacting affected people individually.

Were passwords or credit card numbers taken?

Recruit says none of the four groups includes payment information such as credit cards, and none includes login passwords. Login IDs were included for C-MATCH dealers and for Recruit staff and contractors.

Why did Nissan and Mitsubishi shut their used-car sites?

Both companies' notices say their official used-car services run on Recruit's system, where the suspicious access was detected. Both suspended their services from about 17:00 on 17 October for safety and to check the impact.

Is Mazda affected?

Kyodo and TBS/JNN report that Mazda stopped updating vehicle information on its official used-car search site because it uses Recruit's service. We did not retrieve a Mazda notice, so this rests on those reports.

Is Carsensor back online?

Yes, in phases. Recruit's notice says services began returning from about 13:00 JST on 22 October, starting with those confirmed safe. Listings may lag because C-MATCH was also stopped.

How did the attackers get in?

Recruit has not said. It describes the cause only as unauthorized access by a third party and says its investigation into cause and scope continues. No CVE or product has been linked.

Has the stolen data been misused?

Recruit says that as of 21 October it had not confirmed any secondary damage. It warns that suspicious contacts using the data may follow.

Would Safeguard have prevented this?

No. The lessons here are about shared platforms, tenant segregation, data minimisation, login protection and vendor contracts, which Safeguard does not manage. Safeguard helps with one shared layer: finding and fixing known vulnerable components in the services you build and the SBOMs your providers share.

Fix it without waiting for upstream

Recruit has not said whether a software flaw was involved, and nothing here suggests one in a particular open source package. But every marketplace, dealer portal and white-label site is built from open source components, and keeping those patched is the part of the stack any platform team can control today.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Carsensor, C-MATCH, Recruit, Nissan or Mitsubishi. Each is a real Safeguard session, and each intro says how the same flow would apply to a team that runs a marketplace or a white-label site for other brands.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For a listing platform, you would run /scan . in the repository of the service that renders a partner brand's search pages, then ask the assistant to add a test that fails if one tenant's service account can read another tenant's inquiry records, approving each edit and command as it runs.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. A platform team could pick the folder that holds its inquiry form service, ask for a migration that replaces the free-text address field with structured prefecture and city fields, and approve or deny every file change before it lands.

Click through it at your own pace, or open it full screen.

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. If an advisory lands on a Saturday evening for a framework your dealer portal uses, the on-call engineer could approve the dependency bump and the test run from a phone, and deny anything that touches production data or access policy until a second person has looked.

Click through it at your own pace, or open it full screen.

To try it on your own services, download Safeguard and follow the CLI docs. For the wider month, read October 2026 security incidents and what would have helped, and for scoping which of your products contain a given component, see SBOM incident response: finding affected products fast.

Quick check

Sources

• Recruit: press release on unauthorized access to Carsensor net and C-MATCH, 21 Oct 2026
• Recruit: PDF version of the 21 Oct 2026 press release
• Carsensor net home page, "Notice from Carsensor" on the service restart, updated 22 Oct 2026
• Recruit: inquiry page for this incident
• Nissan: official used-car search site suspension notice
• Mitsubishi Motors: M・C Net suspension notice
• Personal Information Protection Commission: leak reporting obligations
• Kyodo via Kumamoto Nichinichi: Carsensor leak, Nissan and Mitsubishi suspend used-car sites, 21 Oct 2026
• Kyodo via Kumamoto Nichinichi: Nissan and Mitsubishi suspend used-car search sites, 21 Oct 2026
• Kyodo via Kumamoto Nichinichi: Mazda stops updating its used-car search site, 21 Oct 2026
• TBS NEWS DIG via Yahoo! News: Nissan, Mitsubishi and Mazda affected, 21 Oct 2026
• Security NEXT: Recruit used-car services breach, 22 Oct 2026
• ScanNetSecurity: up to 3,709,551 records may have leaked, 23 Oct 2026
• Car Watch: Recruit Carsensor unauthorized access report
• MoneyPost: Nextage shares fall on Carsensor suspension, 19 Oct 2026

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.