A security scanner actively queries virtually any type of service to collect banners, configuration settings and even entire objects such as ssh keys.
An attacker who achieved control over a target system could poison a response of this target system so that arbitrary data is retrieved from the scanner and stored as a result element.
The Greenbone solution as such takes care not to execute such content and sanitizes it properly for example in case it is displayed in the UI. However, it is stored in the database and if a report is created, the poisoned content could be part of this report.
Tools that consume such content might have less mechanisms to properly handle content and then it might happen that malicious code is executed by or via this tool.
So, a security problem can occur on a system consuming scan reports (such as spreadsheet loading a CSV report) and itself being not properly secured, for example the system itself is not up-to-date or mis-configured - or a user ignores warnings. Another precondition is a scanned system where an attacker already gained control, which might happen because the target system exposed a vulnerability or because the attacker is an insider or the scanned system was added to the network without being detected as stranger.
In no case the actual Greenbone solution gets compromised by the attacker.
What can you do to prevent a bad situation? First of all, exactly what you planned to do by introducing the vulnerability management solution: Timely remediate identified problems. Second, what you should do since ever: apply secure configurations. Third, what you should spread the word about: if a tool like your spreadsheet warns with a dialog not to open something, then do not open. Ultimately preventing such an attack path is not possible. But you can make and keep your infrastructure resilient.
Greenbone is considering to add methods to help users preventing poisoning. Naturally this will have limitations on the one hand and impact on work-flows on the other. We prepare to address so-called CSV injections for the CSV report formats plugins as a start. We welcome further ideas and thoughts.
As a last word, please consider that content poisoning can happen in same way for many other data collection processes you are running in your environment, for example inventory builders. It is also discussed recently for other application types, like DokuWiki.