First of all, cryptographic hash collisions are not found by searching or by chance. They are computed because - for some reason - the hash algorithm is broken. You'd still have to create about $2^{128}$ hashes to find a collision after all, even if you take the birthday bound in - and remember that you'd have to perform a compare as well, although there are tricks to speed that up.
Instead the team that performs the analysis will find a weak spot and exploit it, sometimes requiring a lot of resources. This also means that if you create a collision that you are likely to be able to create more collisions using the same methodology.
If a relatively small amount of internal states are affected then it may be possible to fix the hash - hardened SHA-1 for instance is protected against the SHAttered attack. Of course, now that SHA-1 is shown to be weak, there is plenty of reason to migrate to e.g. SHA-256 anyway, and I haven't seen an uptake in hardened SHA-1 anywhere.
Even if you have only two inputs generating the same hash value you may be in trouble. Hashes internally operate block-by-block. If it is possible to find a collision then the next blocks will also be vulnerable. In other words, if you find $H'(B_1) = H'(B_2)$ then $H'(B_1 \| E) = H'(B_2 \| E)$ where $\|$ is concatenation. Note that extension $E$ may contain any data. So in that sense: if you find one collision for SHA-256 then you've found many collisions of messages that start with a particular block or blocks of data.
For SHA-3 the situation is a tad more complex (it depends if the internal state - i.e. the capacity of the used sponge - is identical before or after the final operation) but basically you'd still be in trouble.
If these kind of collisions are applicable to your protocol is another question. Schemes such as HMAC that rely on a hash function are not affected at all, as it doesn't require collision resistance from the configured hash function.
