It depends on the vulnerability, and on the threat environment (as is true for every component, not just development ones). Here are a few (generic) examples:
A tool that fetches an external script from a specified location, and executes it. Vulnerability: The library fetches the script over HTTPS but does not validate the certificate. Exploitable: YES, a man-in-the-middle network attacker can replace the expected, trusted script with a malicious one to gain code execution on your machine.
An application framework that, when launched for debugging, starts the application on one port and a debug service on another. The debug service can be used to control the program execution. Vulnerability: The debug service listens on all interfaces and is unauthenticated. Exploitable: YES, either a network attacker (if not blocked by a firewall) or a low-privilege user on the same host can connect to the debug server to gain control of the application, resulting in arbitrary code execution.
Same as above, but the debug interface is instead a local (Unix) socket. Vulnerability: The socket is globally accessible. Exploitable: PROBABLY, in that any other user (or process running as another user) on your system can use the local socket to gain code execution as you. However, if the machine is single-user (no other users have code running) and the server doesn't have higher privileges than anything else (no opportunity for EoP), then it doesn't matter in that case.
A tool that cryptographically signs publishable files. Vulnerability: The tool incorrectly truncates signatures longer than 4096 bits, resulting in less-secure and incorrect signatures. Exploitable: UNLIKELY, since RSA keys longer than 4096 bits are quite uncommon in practice, as 4096 bit RSA keys are already quite secure. Additionally, if you did use one, you'd hopefully notice that the signature doesn't validate... although if you didn't, that could cause problems for the consumer of your published files (which might be your own company) if they can't validate the files and/or if they use a validator which does validate the files (due to performing the same truncation) but the truncation makes it much easier to modify the files without invalidating the signature.
A tool that generates files from templates. Vulnerability: The tool may incorrectly place the generated files relative to the system root rather than the current directory. Exploitable: UNLIKELY as the chances that the generated files accidentally overwriting anything are very low unless their directory structure resembles the system root are low, and the tool presumably does not run with elevated privileges and thus can't overwrite most files anyhow. A malicious dependency that appears benign could exploit this, causing the overwrite of e.g. your ~/.ssh/authorized_keys with a malicious value (if the vulnerable tool is used with it) without directly containing malicious code itself, but such an attack is very unlikely (and would technically be a supply-chain attack, just sneakily riding another tool's bugs).
A tool that, among other things, can update Jira work items based on your commit messages. Vulnerability: The Jira integration first attempts HTTP for every request, only upgrading to HTTPS if redirected (as Jira normally does). Exploitable: DEPENDS on whether you use Jira or not. If you do, a network attacker can steal your Jira creds and make changes as you. If not, though, this vulnerability is irrelevant to your environment.
A tool that uploads the results of a static analysis to a server over HTTPS. Vulnerability: The tool packages a version of OpenSSL that contains a denial-of-service vulnerability when used as a TLS server. Exploitable: NO, the tool does not act as a TLS server, only as a TLS client, so the vulnerability is irrelevant to its use case.
