>>>I was wondering what it means to have a security exploit in a library that is used by our application.
>>>
>>>For instance we are using 7-zip for compression in our application (for instance to create backup files), which we install through our setup program in a folder together with our application. We don't actually install 7-zip application, but just copy the libraries that are then used by our application.
>>>
>>>As an example, there were security updates for 7-zip in the past because of vulnerabilities (https://www.groovypost.com/news/serious-security-exploits-found-in-7-zip-update-available/)
>>>
>>>What would that mean for our application, if we won't update the 7-zip libraries on time, how would an attacker be able to take advantage of those libraries to exist in our application folder? I am not sure if the fact that these libraries are only used from our application don't pose a security risk, because they are actually not used directly by the user, or does the simple fact of their existance already give an attacker the possibility to exploit those vulnerabilities? Yes, however small.
>>
>>Almost all software has bugs. Some may turn out to be security vulnerabilities; Torvalds claims the latter are usually the former: https://it.slashdot.org/story/17/11/20/1412241/security-problems-are-primarily-just-bugs-linus-torvalds-says
>>
>>If you're interested in a particular CVE you could research what's known about it and reach your own conclusions. However, security researchers and hackers of all shades are endlessly imaginative; black hat hackers may keep some knowledge/exploits secret.
>>
>>In a perfect world everyone would keep their 3rd party libraries continuously up-to-date (a la Windows Update or similar). If there's a formal process in place for that, then they can use adherence to best practices as a defense in case of litigation. If they don't, and an audit of a compromised server finds vulnerable software, well, let's just say lawyers can be endlessly imaginative as well.
>>
>>Another approach is to purchase appropriate insurance, so the risks associated with problems like this are borne by someone else.
>
>So to understand it properly, the sole existance of a dll or executable in the program folder can be at risk of an exploit?

Yes.

>If that is true, what if I package the dll inside of our executable, and for using it by our application, extract it to a temporary location, and remove it afterwards? Would that not solve the problem of having outdated software present on the client's file system?

Referring to Martina's message, that would stop her example #2 (Trojan present on computer using it directly), but #1 would still be in effect. If a user processed a malformed archive using your app and its vulnerable 3rd party libraries, it could lead to compromise.

Now, if you can 100% guarantee that those libraries would only ever process "clean" files or archives (even if a Trojan starts and runs your app), and the libraries don't persist on disk, that might be acceptable.