Security fixes often turn silent acceptance into an error: a value that used to pass through now raises an exception or returns a failure code. Before merging, find the new error paths, check that your code catches them without crashing or leaking details, and test with the input that triggers each one.
Why fixes add errors
If a library was vulnerable because it accepted bad input, the fix usually rejects it. A path with traversal sequences, a URL pointing somewhere forbidden, an oversized body, a malformed token: all of them used to work and now fail. The library tells you by throwing an exception, returning an error object, or sometimes returning a null value.
Your code was written for the old behavior. It may not have a handler for the new failure, or its handler may be too broad or too narrow.
Three failure shapes
| What the library now does | What goes wrong in your code |
|---|---|
| Raises a new exception type | Not caught, so the request crashes or returns a server error |
| Returns an error value instead of a result | Code uses the result as if it were valid, leading to a later failure far from the cause |
| Returns empty or null for rejected input | Missing data is treated as a valid empty value, causing silent data loss |
The second and third are the dangerous ones, because nothing fails loudly.
How to find the new paths
- Read the release notes for words like rejects, raises, throws, invalid, error and now fails.
- Read the diff for new throw or return statements near the fixed code. Our post on reading the diff between two package versions shows how.
- Read the docs for the new version. The error section often lists what can be raised.
- Search your code for calls to the changed function and look at what surrounds each call.
Test each path on purpose
For every call site, send the input that now triggers the rejection and look at the result. Ask these questions:
- Does the user see a clear error, not a stack trace?
- Is the HTTP status sensible, usually a 4xx for bad input and not a 500?
- Does the failure leave data half written? Check transactions and cleanup.
- Does your logging record enough to debug without recording secrets or personal data?
- Does a retry loop hammer the service because the failure is permanent?
Handle errors safely
Catch the specific exception, not everything. A blanket catch hides unrelated bugs. Return a generic message to the user and log the detail internally. Do not echo library error text back to clients, since it can reveal paths, queries or configuration. Our post on whether errors leak internals in code review is a useful checklist.
Do not "fix" the new error by catching it and continuing as if the input were fine. That throws away the protection the fix was meant to add. If legitimate input is being rejected, change the producer or the validation, with a clear reason.
Add a regression test
Add a test for each new rejection: this input must be refused, with this status, and must not crash. Those tests document the new behavior and keep it from being quietly removed later.
Safeguard's dependency scanning shows where a library is used across services, and its policies and gates can require review of changes to sensitive dependencies. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Should I catch all exceptions around the library call?
No. Catch the specific ones you can handle. A blanket catch can hide real bugs and may let rejected input continue as if it were valid.
What status should rejected input return?
Usually a 4xx for client mistakes, with a generic message. A 500 for bad input suggests the error went unhandled.
Last reviewed: 19 October 2026.
