An extensible commercial software system was upgraded to the next minor release version to patch a security vulnerability. After the upgrade, an unauthorized intrusion into the system was detected…

Question

Options

• AThe company's IDS signatures were not updated.
• BThe company's custom code was not patched.
• CThe patch caused the system to revert to http.
• DThe software patch was not cryptographically signed.
• EThe wrong version of the patch was used.
• FThird-party plug-ins were not patched.

• A
  7% (2)
• B
  77% (23)
• C
  13% (4)
• E
  3% (1)

Explanation

The key word is 'extensible' - meaning the system supports customization via custom code and third-party plug-ins. When a commercial vendor releases a patch, they update and test only their own core components. They have no visibility into, or responsibility for, custom code the company has written (B) or third-party plug-ins/extensions developed by external parties (F). If the patched vulnerability also existed in custom logic or a plug-in (through similar flawed patterns or dependent libraries), those vectors remain exploitable after the core upgrade. This is a common oversight in patch management for extensible platforms (e.g., CMS platforms, ERP systems). The vendor confirming core components were updated properly makes B and F the only logical gaps. IDS signatures (A), cryptographic signing (D), and wrong version (E) are not relevant since the vendor confirmed the patch was applied correctly.

No community discussion yet for this question.