### Summary In affected versions, Bugsink stores every tag supplied with an incoming event. An event with an unusually large number of custom (i.e. supplied by an attacker) tags can therefore make ingestion spend more time than intended writing tag rows. Bugsink uses a single-writer database architecture. That keeps the implementation simple, but it also means one expensive write transaction can delay other event digestion while it is running. In this case, it makes ingestion of other events wait until the transaction that writes the tags finishes, which effectively causes a temporary denial of service for other events. ### Impact Submitting such an event requires a valid project DSN. DSNs are sometimes visible in client-side applications, so they should not be treated as a strong security boundary, but the issue is still limited to ingestion for a Bugsink instance that accepts the event. The impact is availability-only. The issue does not expose stored data, modify existing events, or allow code execution. ### Mitigation Update to version 2.2.2, which caps the number of tags stored for a single event. The default cap is 100 tags and can be changed with `MAX_EVENT_TAGS`.
### Summary In affected versions, Bugsink stores every tag supplied with an incoming event. An event with an unusually large number of custom (i.e. supplied by an attacker) tags can therefore make ingestion spend more time than intended writing tag rows. Bugsink uses a single-writer database architecture. That keeps the implementation simple, but it also means one expensive write transaction can delay other event digestion while it is running. In this case, it makes ingestion of other events wait until the transaction that writes the tags finishes, which effectively causes a temporary denial of service for other events. ### Impact Submitting such an event requires a valid project DSN. DSNs are sometimes visible in client-side applications, so they should not be treated as a strong security boundary, but the issue is still limited to ingestion for a Bugsink instance that accepts the event. The impact is availability-only. The issue does not expose stored data, modify existing events, or allow code execution. ### Mitigation Update to version 2.2.2, which caps the number of tags stored for a single event. The default cap is 100 tags and can be changed with `MAX_EVENT_TAGS`.
Update bugsink to 2.2.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanBugsink: DOS using large numbers of event tags affects bugsink (pip). Severity is medium. ### Summary In affected versions, Bugsink stores every tag supplied with an incoming event. An event with an unusually large number of custom (i.e. supplied by an attacker) tags can therefore make ingestion spend more time than intended writing tag rows. Bugsink uses a single-writer database architecture. That keeps the implementation simple, but it also means one expensive write transaction can delay other event digestion while it is running. In this case, it makes ingestion of other events wait until the transaction that writes the tags finishes, which effectively causes a temporary denial of service for other events. ### Impact Submitting such an event requires a valid project DSN. DSNs are sometimes visible in client-side applications, so they should not be treated as a strong security boundary, but the issue is still limited to ingestion for a Bugsink instance that accepts the event. The impact is availability-only. The issue does not expose stored data, modify existing events, or allow code execution. ### Mitigation Update to version 2.2.2, which caps the number of tags stored for a single event. The default cap is 100 tags and can be changed with `MAX_EVENT_TAGS`.
AI coding agents often install or upgrade packages automatically in pip. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| bugsinkpip | <=2.2.1 | 2.2.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate bugsink to 2.2.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanBugsink: DOS using large numbers of event tags affects bugsink (pip). Severity is medium. ### Summary In affected versions, Bugsink stores every tag supplied with an incoming event. An event with an unusually large number of custom (i.e. supplied by an attacker) tags can therefore make ingestion spend more time than intended writing tag rows. Bugsink uses a single-writer database architecture. That keeps the implementation simple, but it also means one expensive write transaction can delay other event digestion while it is running. In this case, it makes ingestion of other events wait until the transaction that writes the tags finishes, which effectively causes a temporary denial of service for other events. ### Impact Submitting such an event requires a valid project DSN. DSNs are sometimes visible in client-side applications, so they should not be treated as a strong security boundary, but the issue is still limited to ingestion for a Bugsink instance that accepts the event. The impact is availability-only. The issue does not expose stored data, modify existing events, or allow code execution. ### Mitigation Update to version 2.2.2, which caps the number of tags stored for a single event. The default cap is 100 tags and can be changed with `MAX_EVENT_TAGS`.
AI coding agents often install or upgrade packages automatically in pip. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| bugsinkpip | <=2.2.1 | 2.2.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard