Is it unethical to write code for a framework with security risks?

In a frictionless ethical vacuum, I think it's pretty clear that knowingly contributing to shipping any severe defect in any product people rely on (or can be reasonably anticipated to rely on) is wrong. It's an engineer's responsibility to society to ensure that the products they work on function and do not cause harm. Software with vulnerabilities is defective and affords the opportunity for harm, in a not too dissimilar way to a faulty airbag (if you ignore the magnitude of the harm being done, obviously a malfunctioning airbag is generally more dangerous).

Your boss's knowledge factors into it in that it is relevant to your forming a professional opinion about whether those conditions are met.

Outside of frictionless ethical vacuums there can be many confounding factors, eg, if making an issue of it would put you at risk of being fired and not being able to fulfill responsibilities to your household, then I think it is okay to take that into consideration, especially if you've made your views known & thus given your boss the opportunity to course correct.

ETA: Reminds me of this conversation a week ago about coming up with a professional code of ethics for software engineers. https://news.ycombinator.com/item?id=33805884

It's good to have principles, but they must be weighed against what actual harm might arise and if it's actually your responsibility. If you had been aware of half the holes in M$ which have been "fixed" over the years (from what I'm told there's still a few despite being informed, that have been carried though for near 20 years) would you have programmed for anyone who wanted a product to run on M$? Obviously most people continue to write programs that ran on M$, since it is quite easy to see that a great amount of people use nothing else.

Since .NET is not proprietary any more, there's a good chance ALL of the issues are being addressed for the next version, unlike M$ who held onto a few of them knowing that eventually they might need an ace to "push."

Out of interest, as a end user myself, as well as what I might install for the average user, I have actively avoid .net products ... too many on offer were written poorly and it's too hard to vet every single one, as well as nasty surprise requirements. This may have changed in the last 8 years or so. On the other hand a coder who could push the same in C++ I could trust, along with most products which employed a good coding team.

Is there any framework that doesn't have security holes?

It highly depends. Are you writing something with customer data? If I am writing some internal tool that is devoid of customer data just internal configuration I would have no problem with that.