[elhoim]

BLUF — An IPQualityScore API failure raises an unhandled RuntimeError instead of a usable error message.

• Problem — RequestHandler.get() in expansion/ipqs_fraud_and_risk_scoring.py uses a bare raise inside a try body when the API returns success: false, producing RuntimeError: No active exception to reraise, which the surrounding except (ConnectTimeout, ProxyError, InvalidURL) does not cover.
• Fix — adds a module-level IPQualityScoreError carrying the API message, raises that instead, and wraps the ip/url/email/phone/username/password dispatch in handler() with a try/except returning misperrors.
• Effect — a bad key, exhausted quota or malformed IOC now surfaces the API's own reason rather than a traceback; the file-type branch is unchanged in behaviour.

The defect

In RequestHandler.get(), when the IPQualityScore API responds with success: false, the handler sets the error message and then executes a bare raise inside the try body — not inside an except clause:

if str(response["success"]) != "True":
    msg = response["message"]
    logger.error("Error: %s", {msg})
    misperrors["error"] = msg
    raise

A bare raise with no exception currently being handled produces RuntimeError: No active exception to reraise. That RuntimeError is not a member of the except (ConnectTimeout, ProxyError, InvalidURL) tuple that wraps this code, so it propagates straight out of get(), out of handler(), and out of the module entirely.

Impact

Whenever the IPQualityScore API reports a failure for an enrichment lookup (bad/expired API key, over quota, malformed IOC, etc.), the module crashes with an unhandled RuntimeError instead of returning the informative error MISP module callers expect. An analyst enriching an attribute sees a generic module crash/traceback instead of the actual reason the IPQS lookup failed, which is unhelpful for triage and makes the failure harder to diagnose.

The fix

Introduced a module-level IPQualityScoreError exception carrying the API's error message and raised that instead of the bare raise. handler()'s ip/url/email/phone/username/password lookup dispatch is now wrapped in a try/except IPQualityScoreError: return misperrors, so an API-reported failure now returns the standard MISP module error response instead of crashing. The file_query_input_type branch, which is mutually exclusive with the wrapped branches, was changed from elif to a separate if to accommodate the new try block; behavior for file-type attributes is unchanged.

The two other raise statements the finding also flagged (:158, :183) were left as-is: they sit inside except HTTPError as error: blocks where an exception is genuinely active, so they are correct re-raises, not the described defect.

Behaviour change

Before this fix, an IPQS API failure crashed the module with an unhandled RuntimeError. After this fix, it returns misperrors with the API's error message, which is the module's documented error-reporting contract — this brings the failure path in line with how every other error in this module is already reported, rather than introducing new behavior.

Verification

• flake8 --extend-exclude=misp_modules/lib/,tests/,website/ on the changed file: clean, no output.
• python -m py_compile misp_modules/modules/expansion/ipqs_fraud_and_risk_scoring.py: succeeds.
• Full module test suite: 161 passed, 4 skipped, 5 subtests passed in 150.44s (0:02:30).
• Verified the module still imports cleanly on the live test server (log line: MISP module ipqs_fraud_and_risk_scoring (type=expansion) imported).

Found during a review of the repository; other findings are being submitted as separate PRs.

🤖 Generated with Claude Code