Last updated: August 24, 2026
Email contact@yaw.sh with "Security" in the subject. Please include the Yaw version, your operating system, and enough detail to reproduce the issue. If you believe the issue is being actively exploited, say so in the subject line.
We will acknowledge your report, tell you whether we consider it a vulnerability and why, and let you know when a fix ships. Please give us a reasonable window to release a fix before publishing. We do not run a paid bug bounty, and we will credit you in the release notes if you would like to be credited.
Every artifact of every release is listed with its SHA256 in one file: downloads.yaw.sh/SHA256SUMS. That covers the Windows, macOS, and Linux archives plus the .deb, .rpm, AppImage, and Flatpak packages.
The same hashes also appear in the package manager manifests - scoop-yaw for Windows and homebrew-yaw for macOS. Because those are public git repositories, the value published for any given release is recorded with a timestamp and cannot be revised later without leaving a commit behind.
Be clear about what that does and does not buy you. All three are published by the same release process using the same credentials, so they are not independent attestations - somebody able to rewrite one could very likely rewrite the others. What the git history does give you is evidence of change over time: a hash that was altered after publication is visible as a commit, and a hash you recorded when you first deployed Yaw can be compared against the one being served today. That is a real property, and it is a narrower one than "two sources agreeing".
The hash covers the distributed archive, not the executable inside it. This matters in exactly the situation that brings most people to this page: if your tooling flagged yaw.exe and you hash that file, it will not match, and that is expected rather than evidence of tampering. Hash the archive that was downloaded.
Get-FileHash yaw-win32-x64-<version>.zip -Algorithm SHA256shasum -a 256 yaw-darwin-arm64-<version>.zipsha256sum yaw-linux-x64-<version>.zipSHA256SUMS alongside the artifacts and run sha256sum -c SHA256SUMS --ignore-missingIf the archive is no longer on disk, re-download it from the URL in the manifest for that version and hash that. Note that a re-download proves the published artifact is intact; it does not prove the copy already installed was not altered afterwards, so if you are investigating a specific machine, hash the archive from that machine where you still can.
If Yaw was installed through Scoop or Homebrew, the package manager already checked this hash at install time and refuses to proceed on a mismatch - a successful install is that check having passed.
If the hashes do not match, treat the binary as modified and tell us - a mismatch is worth investigating regardless of what it turns out to be.
Yaw is not currently signed with a certificate from an authority your operating system recognizes, on either platform. That is changing on both, and this section describes exactly where each one stands. We would rather state the current position plainly here than have you discover it from an alert.
macOS builds are currently signed with a self-signed certificate, not an Apple Developer ID, and are not notarized. Organization enrollment in the Apple Developer Program is underway. Once it completes, releases will be signed with a Developer ID Application certificate and submitted to Apple for notarization, so Gatekeeper can attribute the binary to a verified organization rather than treating it as unidentified.
Windows builds are not Authenticode-signed. We are working on this as well. Since mid-2023 the CA/Browser Forum baseline requirements have obliged code-signing private keys to live in certified hardware, which rules out the simple certificate-file approach and makes this a question of fitting a hardware-backed or cloud-HSM signing service into an automated release process.
Our honest expectation for both is approximately the next one to two months. Entity verification and certificate issuance are not processes we control the pace of, so we are not going to publish a date we cannot stand behind - but the direction is settled and the work is in progress rather than under consideration.
The self-signed macOS identity in use today is deliberately kept constant across releases: macOS ties keychain and Safe Storage access grants to the code signature, so a stable identity means the permission you granted once persists instead of re-prompting on every update. Because that certificate is not issued by Apple, macOS treats the app as unidentified, and depending on how you installed it you may have to allow it explicitly on first launch. Moving to a Developer ID identity changes the signature, so expect a one-time re-prompt for those grants on the release where that lands.
Until signing is in place, the absence of a recognized publisher is the single largest reason enterprise endpoint tools escalate Yaw to a high-severity alert. With nothing to attribute the binary to, ordinary application behavior is evaluated entirely on its own merits, and a terminal emulator's ordinary behavior looks a great deal like the techniques described below.
A signature will not make the SHA256 comparison above redundant, and we would rather you keep relying on it either way. It does not depend on us being vouched for by a certificate authority - only on the hash you compute matching the hash published in a public, version-controlled manifest whose history you can read.
For allowlisting, that hash is also a more precise identifier than a publisher name: it identifies exactly one build of one version, rather than everything a given certificate has ever signed. If your policy requires a signed binary today and a hash will not satisfy it, we would rather you wait for the signed build, or not run Yaw at all, than work around your own controls.
Yaw is a terminal emulator built on Electron. Both of those facts produce behavior that overlaps with techniques malware uses, and on an unsigned binary that overlap is usually enough to generate a critical alert. Below is each detection we see reported, what actually causes it, and how to check the claim yourself rather than take our word for it.
Electron passes a --preload script argument to its renderer, and spawns child processes from the same executable image (--type=renderer, --type=gpu-process, --type=utility). Separately, the terminal backend creates Windows pseudoconsole (ConPTY) sessions, which duplicate handles into child processes so a shell can read and write the terminal.
Those three behaviors match hollowing and injection heuristics, but they are standard framework operation. Yaw contains no calls to CreateRemoteThread, VirtualAllocEx, WriteProcessMemory, NtUnmapViewOfSection, or SetWindowsHookEx. That is verifiable by static inspection of the binary's import table.
Yaw is a terminal emulator. Every shell a user launches inside it - PowerShell, cmd, WSL, Git Bash - is a child process of yaw.exe. If a user runs a base64-encoded command, Yaw is the parent process, not the author of the command. This is the application working as intended, and it is worth separating from Yaw's own behavior when triaging.
Yaw itself runs PowerShell in one place: the updater. See Updates below.
Yaw registers the yaw:// URL scheme under HKCU\Software\Classes\yaw so that install links work. That is the only registry key Yaw writes for itself.
There is no Run key, no scheduled task, and no auto-start entry. Yaw does not start with Windows. If your tooling recorded a specific key path, we encourage you to check it against that claim.
Yaw encrypts the SSH keys, database passwords, and API keys you save into it, using Electron's safeStorage, which on Windows calls DPAPI (CryptProtectData / CryptUnprotectData). Credential-stealing malware calls the same operating system APIs, which is why this triggers a detection. The direction is the opposite: this protects credentials you entered, it does not collect them.
On browser credential stores specifically, Yaw goes further than not reading them. Its file-read path carries an explicit denylist that refuses Cookies, Login Data, and their SQLite journal siblings, alongside .pem, .key, .env, and credentials.* files. Those filenames appear in the source only inside that denylist.
Nothing Yaw encrypts locally is ever transmitted to us. The privacy policy lists every network request Yaw makes on its own.
On Windows, updating requires replacing files that are locked while the application is running, so Yaw writes an update script to a temporary directory, exits, and runs that script with PowerShell. The invocation uses -ExecutionPolicy Bypass -WindowStyle Hidden, because the script is generated locally rather than signed, and because the application has already exited so there is no window to attach to. That combination is also a well-known malware pattern, which is why it draws attention. The script is written to the user's temp directory and can be inspected.
Before updating, that script fetches a short maintenance script from yaw.sh. It exists so that update-flow bugs can be fixed without shipping a new binary. From version 2.0.27, Yaw refuses to execute it unless a cryptographic signature over the exact bytes served verifies against a public key compiled into the application, with the signing key held offline. An unsigned or altered script is skipped, and the update proceeds without it.
We added that verification after reviewing this mechanism ourselves. Prior to 2.0.27 the script was fetched over HTTPS and executed, which means a compromise of our own site or CDN could have been used to run code on updating installations - HTTPS authenticates the server, but it does not protect against the server itself being wrong. We have no indication this occurred, and the script served has only ever been our own update-cleanup logic. We are documenting it here because we would rather disclose it than have you find it.
If Yaw has been flagged in your environment and you need something this page does not cover - a specific detection, an artifact your tooling captured, or written confirmation for a review - email contact@yaw.sh. Yaw is a developer tool that people install deliberately, and we would rather answer the question directly than have it resolved by a block rule.