Yamaha screwed up, let's talk about it
A security vulnerability report was filed to Yamaha on June 6th, 2026. I was left without a response and between June 23rd and July 2nd, I had an email conversation with JPCERT/CC. Since July 2nd, I have been left without information or a response from either side. As 60 days has passed since the initial report date, I have made the decision to make this information public, largely to incentivize Yamaha to fix the vulnerability.
Before you read on I'd like to mention that it's more than possible I'm biased, and that likely, unfortunately, shows in this post. I'm a man with opinions, don't hate me.
Update, August 5th, 2026 (a few hours after publishing): I was made aware that Yamaha quietly released VOCALOID6 Editor 6.13.1 two days ago, on August 3rd. I've since taken a little look at it too and the short version is that it's a partial mitigation from them and not a full fix. And it actually confirms they saw my report! (woo!)
In 6.13.1 the Editor no longer assigns the content-store and telemetry credentials in plaintext inside VSGMain.Initialize(), but they've rather been moved into a native library and are no longer sitting in the managed C# for anyone to read in a few seconds, so credit where credit is due!
BUT...
- The credentials were not rotated! The keys in 6.13.1 are the exact same keys as before. Every earlier release (6.12.0.1 through 6.13.0) is still available from alternate sources and still ships them in plaintext, so the secrets are exactly as exposed today as they were the day I filed the report. Relocating them out of the newest binary means nothing until they're actually rotated.
- The activation credentials are still shipped in plaintext! Just in the VOCALOID Authorizer now rather than the Editor.
- The Bridge issue is completely unchanged!
- The code is still unobfuscated!
So honestly everything described below is still live. What's notable to me is that this shipped silently, with no reply to me and no advisory to users... which is, uh, precisely the reporting-process complaint I make further down, so make of that what you will.
Update, August 22nd, 2026: An advisory (JVNVU#90210212) was published by JPCERT on August 21st. It is available here:
https://jvn.jp/en/vu/JVNVU90210212/
I have since asked JPCERT to make some corrections to the advisory, and am awaiting a response.
Two CVE identifiers were assigned and can be found here:
https://www.cve.org/CVERecord?id=CVE-2026-76131
https://www.cve.org/CVERecord?id=CVE-2026-76137
The activation server and content store issues were combined into one identifier (CVE-2026-76131), and the telemetry endpoint was not assigned one. The Bridge issue was assigned CVE-2026-76137.
Update, August 27th, 2026: Yamaha has published 6.13.2, which claims to fix the issues published by JPCERT. I haven't confirmed whether everything was fixed, but you should either way update:
Summary: In early June I discovered that Yamaha had left production secrets, URLs, and more in shipped VOCALOID6 binaries that would allow malicious actors to do a whole lot of stuff I detail below.
This post is very different from anything I'd ever post, and ever will post, but it's something I want out there!
On June 5th, 2026, I was looking around the VOCALOID6 binaries using a tool called ILspy. In my defense, I was bored, and I wanted to see what UI framework Yamaha had chosen. It's WPF, by the way.
After some investigation, if you can call it that, I stumbled across some development material. Namely, I stumble across the entire unobfuscated code that tells the editor how to activate voicebanks. Yikes!
I investigated more and notice that not only did they not obfuscate the one thing keeping their software from being as easy to crack as an egg, they left production secrets in the compiled consumer binary, that the editor is supposed to use not only to activate licenses, but also to send telemetry data, download asset packs that should be limited to VOCALOID owners, check if a license is active/valid, and—arguably worst of all—lets malware hook itself into VOCALOID via the VOCALOID Bridge and perform actions that appear to be by the VOCALOID6 Editor. Let's go over everything in as much detail as I possibly can without getting sued by a Japanese billion-dollar company!
The activation server (CVE-2026-76131)
The short version of this part is that Yamaha had—whether accidentally or on purpose, almost certainly the former—hardcoded secrets into the Editor's code.
In VSGMain.Initialize(), which runs on Editor startup, the production credentials (redacted below) are assigned in plaintext to singleton instances:
public static void Initialize() {
VCSServerAPI api = VCSServerAPI.Shared();
VCSActivationAPI act = VCSActivationAPI.Shared();
api.BaseURL = "redacted";
act.BaseURL = "redacted";
api.AppKey = "redacted";
api.AppSecret = "redacted";
act.AccessKey = "redacted";
act.SecretKey = "redacted";
}
If this isn't exciting enough for you, you'll also be happy to find out that they did this again, further into the activation code, where the entire authentication header the Editor/Authorizer uses is ALSO exposed:
Authorization: X-YamahaVocaloid AccessKey=redacted,Date=<date>,Signature=<hex>
The signature is generated with an HMAC construction whose secret is also embedded in the client.
The activation flow also exposes the exact request/response JSON bodies, but for obvious reasons (read: Yamaha may not want to change these and I don't want to be sued) I won't be going into more specifics about them.
In short, anyone holding AccessKey and SecretKey can send signed validation requests to Yamaha's live activation server (as if they were the VOCALOID6 Editor), query the validity and remaining activation count of any activation code they supply, determine exactly what/which componentIDs are registered to an activation code, and see whether a code has been used up.
The content store (CVE-2026-76131)
Now this is less bad compared to the activation server, but still exposes authentication secrets the editor uses to identify itself to Yamaha's content API.
The Editor talks to a separate API used for news, version checks, the catalogue of available voicebanks and—most importantly—the metadata needed to download content packages. Like before, the base URL, application key, and application secret are all assigned in plaintext in VSGMain.Initialize(). Open the DLL, search for the method, and there they are!
For most requests the Editor simply sends HTTP Basic authentication made from the application key and secret, but for the content-detail endpoint, Yamaha seemingly decided Basic authentication was not enough and added a second HMAC signature header. That would be a perfectly reasonable thing to do if the secret needed to create the signature wasn't sitting directly beside the code that creates it.
Lawsuit material removed, the request looks something like this:
POST /api/v2/contents/{id}
Authorization: Basic redacted
X-Vapi-Content-Authorization: Signature AccessKey=redacted,Timestamp=<unix_timestamp>,Signature=<hex>
The signature is produced using essentially the same double-hash construction as the activation API, where the method, URI, body, access key, and timestamp are combined, hashed, and then signed using the exposed secret.
The authentication scheme Yamaha chose is, in itself, fine... just not when you give every person with a copy of VOCALOID6 all the material required to make anything authenticate as the official client!
The telemetry endpoint (no CVE assigned)
The short version of this part is that Yamaha also shipped the write credential for their Google Analytics property.
Like most software, VOCALOID6 sends telemetry through Google Analytics 4's Measurement Protocol. The Editor reports things like session starts and ends, which voicebanks you use, which commands you execute, parameter edits, style preset changes, the installed version, language, region, and a lot of other usage information.
Whether you personally like that amount of telemetry is a separate discussion (I know I don't). The vulnerability here is that the Measurement Protocol api_secret used to submit those events is, you guessed it, embedded in the same unobfuscated consumer binary.
A GA4 Measurement Protocol secret does not let someone download Yamaha's analytics dashboard, just to be clear. This is a write credential, which means anyone who has it can submit fabricated events to the property while pretending to be a legitimate VOCALOID6 client.
That makes it possible to poison Yamaha's analytics with invented sessions, fake feature usage, arbitrary command events, made-up application versions, and whatever other values the endpoint accepts. At best this produces junk data some poor employee needs to clean up, at worst, it can distort the information Yamaha uses to make product, engineering, or business decisions.
The VOCALOID Bridge (CVE-2026-76137)
The short version of this part is that any local process can send an unauthenticated file-open command to a running VOCALOID6 Editor.
VOCALOID6 uses a named pipe and a memory-mapped file as an inter-process communication mechanism. This is fairly standard, in all honesty: another process writes a path into shared memory, connects to the pipe, sends a single byte, and the Editor reads the path and passes it to its Startup() method.
If you have some coding knowledge, reading the server loop should be enough to let you figure out what's wrong:
await serverStream.WaitForConnectionAsync();
await serverStream.ReadAsync(signal);
using var mmf = MemoryMappedFile.OpenExisting(pipeName);
using var acc = mmf.CreateViewAccessor();
int charCount = acc.ReadInt32(0);
acc.ReadArray(4, chars, 0, charCount);
Startup(new string(chars));
See the issue? No? There is no authentication token, no check that the connecting process is a genuine Yamaha component, and no capability negotiation. The signal byte is read, but its value is ignored. Possession of the globally known pipe name gives you effectively the entire protocol, and that name is hardcoded in the binary!
Let me just be extra clear that this is not an RCE by itself and I don't think you should consider it one. An attacker needs to have a process already running on the same Windows machine, likely under the same user account as the pipe, or with greater privileges. What this does provide is an unauthenticated route into a trusted application's file-opening logic.
This is by far the most immediately security-relevant part in my opinion, as malware can cause the Editor itself to process attacker-supplied paths, making the resulting file-open action originate from the trusted VOCALOID6 process. Even if every file parser behind the pipe is flawless, local applications should never accept commands from arbitrary neighbouring processes merely because they know a UUID that is visible in the executable. That is security 101, and it's borderline embarrassing that Yamaha let this pass QC.
How the lack of obfuscation made this very trivial to discover
In this case, obfuscation wouldn't fix the central problem, but Yamaha's complete lack of it turns discovery from a reverse-engineering project into casual browsing.
VOCALOID6.dll can be opened with free and open-source tools like ILSpy and turned into readable C# in just a few seconds. Everything, from class names, method names, fields, URLs, JSON models, authentication code, and control flow, are all presented nearly exactly as a developer would see them in source code.
To Yamaha, regarding your vulnerability reporting process
Fix it.
Reporting this to you was hell. I had to dig around your website for over an hour to find some kind of contact form that would work and I eventually settled on a general customer support form that didn't include Sweden as a selectable region.
I waited seventeen days without any response from Yamaha before contacting JPCERT/CC. JPCERT/CC acknowledged the report three days later, but Yamaha still never contacted me directly.
Thank you. Rant over.
Disclosure timeline
To protect myself from lawsuits, here is a full timeline of my contact with Yamaha and JPCERT/CC.
June 5th, 2026 - I discover the exposed code and credentials while inspecting VOCALOID6 binaries
June 6th, 2026, ~01:30 CEST - I submit the vulnerability report to Yamaha
June 23rd, 2026 - After no response from Yamaha, I contacted JPCERT/CC
June 23rd-July 2nd, 2026 - I exchanged emails with JPCERT/CC and provided analysis material
July 2nd-August 5th, 2026 - I receive no further update from either JPCERT/CC nor Yamaha
August 5th, 2026 - Sixty days have passed since my original report. This post is published.
I originally confirmed the above findings in version 6.12.0.1. I repeated the same inspection against each newer VOCALOID6 Editor release up to and including 6.13.0, and the issues remained present in identical form. Version 6.13.1 (released August 3rd, 2026) partially relocates some of these credentials into native code, but does not rotate them and does not resolve the underlying issues. See the update note at the top of this post for the details.
I have not gained access to Yamaha infrastructure or user data in any way, shape, or form.
My goal with this post is not to make abuse easier, but, as I explained in the beginning of the post, to incentivize and pressure Yamaha to resolve these vulnerabilities and inform users.
I ask that Yamaha rotates every exposed credential, audits logs for abuse, replace the GA4 Measurement Protocol secret, and redesign any client authentication that depends on a globally shared secret. Additionally, the Bridge IPC mechanism should authenticate callers, restrict access through appropriate pipe ACLs, validate the shared-memory object, and treat all supplied paths as hostile input.