I would argue that the failing test should be added, but not explicitly as "a failing test."
As @BenVoigt points out in his answerhis answer, a failing test doesn't necessarily "break the build." I guess the terminology can vary from team to team, but the code still compiles and the product can still ship with a failing test.
What you should ask yourself in this situation is,
What are the tests meant to accomplish?
If the tests are there just to make everyone feel good about the code, then adding a failing test just to make everyone feel bad about the code doesn't seem productive. But then, how productive are the tests in the first place?
My assertion is that the tests should be a reflection of the business requirements. So, if a "bug" has been found that indicates a requirement is not properly met, then it is also an indication that the tests do not properly or fully reflect the business requirements.
That is the bug to be fixed first. You're not "adding a failing test." You're correcting the tests to be a more accurate reflection of the business requirements. If the code then fails to pass those tests, that's a good thing. It means the tests are doing their job.
The priority of fixing the code is to be determined by the business. But until the tests are fixed, can that priority truly be determined? The business should be armed with the knowledge of exactly what is failing, how it is failing, and why it is failing in order to make their decisions on priority. The tests should indicate this.
Having tests which don't fully pass isn't a bad thing. It creates a great artifact of known issues to be prioritized and handled accordingly. Having tests which don't fully test, however, is a problem. It calls into question the value of the tests themselves.
To say it another way... The build is already broken. All you're deciding is whether or not to call attention to that fact.